(19) 



J 



Europfiisches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(11) EP 1 130 844 A2 

EUROPEAN PATENT APPLICATION 



(43) Date of publication: 

05.09^001 Buitetin 2001/36 

(21) Application number: 01104908.7 

(22) Date of filing: 28.02.2001 



(51) lntCl7: H 04 L 9/32 



(84) Designated Contracting States: 


• Ishlbashi, Yoshihito 


AT BE CH CY DE DK ES R FR GB GR IE IT LI LU 


ShInagawa-ku, Tokyo (JP) 


MC NL PT SE TR 


• Futamara, Ichiro 


Designated Extension States: 


Shlnagawa-ku, Tokyo (JP) 


AL LT LV MK RO SI 


• Kon, MasashI 




ShInagawa-ku, Tokyo (JP) 


(30) Priority: 29.02.2000 JP 2000054091 


• Watanabe. HideakI 


24.04.2000 JP 2000123027 


Shinagawa-ku, Tokyo (JP) 


(71) Applicant; SONY CORPORATION 


(74) Representative: Melzer, Wolfgang, DIpl.-lng. et al 


Tokyo (JP) 


Patentanwalte 




IMitscherllch & Partner, 


(72) Inventors: 


Sonnenstrasse 33 


• Matsuyama. Shlnako 


80331 Manchen (DE) 


Shinagawa-ku. Tokyo (JP) 





CM 
< 

00 

o 

CO 



(54) Pubiic-key-encryptton data-communication system and data-communication-system 
forming method 



(57) A public-key-encryption data-communication 
system includes a public- key-certificate issuer authority. 
The publtc-key-certif icate issuer authority performs the 
issuance of a public key certificate and management op- 
erations, certification of a subject to be certificated, 
which is a certificate issuing request, and management 
such as registration processing are executed by a root 
registration authority or each registration authority. The 
public-key-certificate issuer authority perfomis process- 
ing for validating. Invalidating, and deleting the certifi- 
cate In accordance with a request from the root regis- 
tration authority. The root registration authority accepts 
a request for issuing a public key certif teate correspond- 
ing to the subject to be certificated which is under the 
control of a certificated registration authority, and trans- 
fers it to the public-key-certificate issuer authority in a 
form in which a signature is added to it. Processes by 
the public- key -cert if icate issuer authority, the root reg- 
istration authority, the registration authority are separat- 
ed, whereby the need for new implementation of user 
recognition, certificate issuance, registration, and man- 
agement is eliminated. 
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Description 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

[0001] The present invention relates to publlc-key- 
certificate issuing systems for proving the validity of a 
public key for use in encrypted data transmission in elec- 
trons distribution systems, and data communication 
methods, in particular, the present Invention relates to 
a publk;-key-certirtcate Issuing system in which a data* 
transmission-servtee entity enables a public key and a 
public-key certificate to be used for general purposes 
without having a certificate authority function for issuing 
a public-key certificate, and to a data communication 
method. 

2. Description of the Related Art 

[0002] Nowadays, various types of software data 
(hereinafter referred to as "contents"), such as game 
programs, audio data, image data, and document-mak- 
ing programs, are distributed via networks such as the 
Intemet. Also, the purchase and sale of goods via a net- 
work, such as online shopping, has become gradually 
popular. 

[0003] In data communication of the above network 
type, in general, a data transmitting side and a data're- 
ceiving side transfer necessary data to each other after 
verifying that each side is correct, in other words, a data 
transfer system in which security is taken into consider- 
ation is formed. In a technique for realizing a security 
system in data transfer, encr^tion processing on data 
to be transferred and sign processing on data are per- 
formed. 

[0004] By decryption processing based on a prede- 
termined procedure, encrypted data can be restored to 
decrypted data (plaintext) that is usable. Data encryp- 
tion and decryption have been well known in which an 
encryption key is used in encryption processing on the 
information and a decryption key Is used in decryption 
processing. 

[0005] There are various types of data encryption and 
decryption using encryption and decryption keys. One 
example of the types is a so-called "public key encryp- 
tion". In the public key encryption , by using different keys 
for a transmitter and a receiver, one key is used as a 
publk: key that can be used by unspecified users, and 
the other key is used as a private key that is kept secret. 
For example, a data encryption key is used as a public 
key, and a decryption key is used as a private key. Oth- 
erwise, the public key encryption is used in a form that 
uses a certificator generating key as a private key and 
a certificator decrypting key as a public key. 
[0006] The public key encryption is advantageous to 
the management of keys since it differs from a so-called 
"symmetric- key encryption method" using a symmetric 



key for decryption in that a particular person needs to 
have a private key that must be kept secret. However, 
since the symmetrrc-key encryption method has a slow- 
er data processing speed than that of the public key en- 
5 cryption. it is often used for small-data-amount objects 
such as a private key delivery, and digital signing. One 
typical example of the public key encryption is RSA 
(Rivest-Shamir-Aldleman) encryption. This uses the 
product of very large prime numbers (e.g., 150 digits), 
10 and uses diffk:ulty of factorization processing on the 
product of the two large prime numbers. 
[0007] In the public key encryption, a technique is of- 
ten used which is designed allowing the general public 
to use a public key and whk;h uses a public-key certifi- 
es cate certificating the validity of a distributed public key. 
For example. User A generates a pair of a public key 
and a private key, sends the generated public key to a 
certificate authority, and obtains a public-key certificate 
from the certificate authority. User A opens the publk;- 
20 key certificate to the publfc. By obtaining the public key 
from the public-key certificate by performing a predeter- 
mined procedure, an unspecified user encrypts a docu- 
ment or the like, and sends it to User A. User A is a 
system that uses the private key to decrypt the encrypt- 
25 ed document. User A is also a system that puts a sig- 
nature on the document by using the private key and 
that verifies the signature by obtaining the public key 
from the public-key certificate through a predetermined 
procedure. 

30 [0008] The publb-key certificate is described with ref- 
erence to Fig. 1 . The public-key certlf k:ate is a certificate 
issued by a certificate authority or an issuer authority, 
and is a certifteate made such that, by submitting from 
a user the user's ID, a public key, etc., to the certificate 

35 authority, the certificate authority adds information such 
as the ID of the certificate authority and a revocation 
date and also puts a certificate authority's signature. 
[0009] The public-key certificate shown in Fig. 1 in- 
cludes a certificate version number, a certificate serial 

40 number assigned to a certificate user by the certificate 
authority, algorithm and parameters used for eiectronk; 
signing, a ceitifksate authority name, a certificate revo- 
cation date, a certifcate user name (user ID), a publk: 
key for the certificate user, and an electronic signature 

45 of the certificate user. 

[0010] The electronic signature is data generated by 
generating a hash value by applying a hash function to 
the entirety of the certificate version number, the certif • 
k:ate serial number assigned to the certificate user by 

50 the certificate authority, the algorithm and parameters 
used for electronic signing, the certificate authority 
name, the certificate revocation date, the certif cate user 
name, the entirety of the public key of the certificate us- 
er, and the electronic signature, and using a certif icate- 

55 authority private key on the hash value. 

[0011] The certificate authority issues the public key 
certificate shown in Fig. 1 . updates the public-key cer- 
tificate that has expired, and performs the generation, 
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management, and distribution (these are called "revo- 
cation") of an unauthorized person list (or expelling us- 
ers who have taken unauthorized conducts. The certif- 
icate authority also generates a public key and a private 
key, as required. 

[0012] When using the public-key certificate, a user 
uses the certificate authority public key retained by the 
user to verify the electronic signature on the public-key 
certificate, extracts the public key from the public-key 
certificate after succeeding in the verif k:ation of the elec- 
tronic signature, and uses the public key. Accordingly, 
all users who use the publk:-key certifksate must retain 
certificate- authority public keys that are common. 
[0013] In a data transmission system based on the 
above-described public key encryption using a public- 
key certificate issued by a certificate authority, if a dif- 
ferent publte key is used, it is required to newly request 
a certifk:ate authority to issue a public-key certifk:ate 
corresponding to the public key, or it is required to con- 
struct a certification system having a certificate authority 
function. In other words, for example, when a service 
provider that distributes contents or offers a goods pro- 
viding service starts a new service (new electronic dis- 
tribution system) and starts to use a new public key, the 
servk:e provider always must request a certificate au- 
thority to perform the issuance and management of a 
public-key certifcate corresponding to the new public 
key or to construct a certificating system having a cer- 
tificate authority system, so that problems occur in that 
a lot of costs and time are required. In addition, when 
certificates issued by different certificate authorities are 
used to perform communication, it is required, for veri- 
fying issuance authority signatures in the certificates, 
that a signature verifying key be acquired by establish- 
ing a link to a center, and this case is not suitable for 
offline use. 

SUMMARY OF THE INVENTION 

[001 4] Accordingly, it is an object of the present i nven- 
tion to provide a publk;-key-encryption data-communi- 
cation system and data -communication method that 
simplify a pubric-key-certificate issuing system and that 
enable a sen/ice provider to easily use a public-key cer- 
tificate when a service provider starts a new service. 
[0015] To this end, according to an aspect of the 
present invention, the foregoing object is achieved 
through provision of a public-key-encryption data-com- 
munfcation system including a public- key -certificate is- 
suer authority for issuing a public key certificate corre- 
sponding to a subject to be certificated which performing 
data transfer using public key encryption, a root regis- 
tration authority whk:h executes mutual data transfer 
with the public-key-certificate issuer authority, which 
performs certification of the subject when the subject is 
under the control of the root registration authority and 
whk:h requests the publk:-key-certificate issuer author- 
ity to Issue the public key certifteate corresponding to 



the subject: and a registration authority which executes 
mutual data transfer with the root registration authority, 
which performs certification of the subject when the sub- 
ject is under the control of the registration authority and 

5 which requests the root registration authority to issue 
the publk: key certificate corresponding to the subject. 
[0016] Preferably, in the public-key-encryption data- 
communcation system, the root registration authority 
treats a plurality of registration authorities as subjects 

10 to be certificated, and each of the plurality of registration 
authorities treats, as a subject to be certificated, one of 
at least one sen^ice provider, at least one user terminal, 
and at least one user which are under the control of the 
registration authority. 

IS [0017] in the publtc-key-encryption data-communica- 
tion system, the registration authority or at least one 
service provider which is under the control of the regis- 
tration authority may apply, to a plurality of different serv- 
ices, a public key certificate corresponding to a subject 

so to be certificated whch Is under the control of the reg- 
istration authority or of the at least one service provider 
which is under the control of the registration authority. 
[0018] In the public-key-encryption data-communica- 
tion system, the root registration authority may include, 

25 as one of a plurality of registration authorities as sub- 
jects to be certificated whrch are under the control of the 
root registration authority, a clearing center for execut- 
ing settlement processing, and in processing using a 
public key certificate which is issued via the clearing 

30 center, settlement may be performed which relates to a 
service provided by a registration authority other than 
the clearing center which is under the control of the root 
registration authority or by at least one service provider 
which is under the control of the registration authority 

35 other than the clearing center. 

[0019] In the public-key-encryption data-communtoa- 
tion system, the public-key-certificate issuer authority 
may hold a list of the correspondence among public 
keys and corresponding publk: key certificates, and the 

40 identifiers of subjects to be certificated for whk:h the 
public key certificates are issued, and eitherthe root reg- 
istration authority or the registration authority may hold 
entity data which correspond to the subjects and whteh 
include certification data on the subjects. 

45 [0020] In the public-key-encr^tion data-communica- 
tion system, the public key certificates may each include 
an electronic signature field for an electronk: signature 
of the public-key-certificate issuer authority, and a plu- 
rality of algorithms may be used as a signature algorithm 

50 for the electronic signature generated in the electronic 
signature field, and the public key certificates may each 
include a field identifying the used algorithm. 
[0021 ] In the public-key-encryption data-communica- 
tion system, in data transfer between the publk:-key-cer- 

55 tificate issuer authority and the root registration author- 
ity, cross certification processing may be performed, 
and when the cross certification is established, mutual 
data transfer may be executed. In data transfer between 
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the root registration authority and the registration au- 
thority, cross certification processing may be performed, 
and when the cross certification is established, mutual 
data transfer may be executed, and in data transfer be- 
tween the registration authority and the subject, cross 
certification processing may be performed, and when 
the cross certification is established, mutual data trans- 
fer may be executed. 

[0022] In the public-key-encryption data-communica- 
tion system, between two among the publlc-key-certifl- 
cate issuer authority, the root registration authority, the 
registration authority, and the subject, data may be 
transferred in a form in which the data includes a gen- 
erated electron k; signature of a data transmitting side. 
[0023] Preferably, in the public-key-encryption data- 
communrcation system, at least one of the root registra- 
tion authority and the registration authority possesses a 
revocation list concerning public key certificates conre- 
sponding to subjects whk:h are under the control of the 
at least one, executes the updating of the revocation list, 
and requests the pubtk:-key-certificate issuer authority 
to perfomi data processing corresponding to the updat- 
ing. 

[0024] In the public-key-encryption data-communtea- 
tlon system, at least one of the root registration authority 
and the registration authority may request the issuance 
of a plurality of public key certifbates corresponding to 
a plurality of services which are under the control of the 
one authority. 

[0025] In the publte-key-encryption data-commun na- 
tion system, the public key certificate may include a 
common electronic signature of the public-key-certifi- 
cate issuer authority whbh issues the public key certif- 
icate, and one of a root registration auttiority, a registra- 
tion authority, a service provider, and a user device 
whteh perfomn processing for the verification of one pub- 
Ik: key certificate issued by the public-key-certificate is- 
suer authority may perform offline processing for the 
verification of different public key certificates issued by 
a single publk:-key-certificate issuer authority. 
[0026) I n the pubik:-key-encryptton data-commu n ica- 
tion system, the registration authority may be formed as 
a system holder as an authority whch provides or man- 
ages a distribution infrastructure for contents which are 
usable by a user terminal, contents for use in providing 
a service, or a service, and the system holder may con- 
trol and may treat a service provider and the user termi- 
nal as subjects to be certifk^ated. 
[0027] Preferably, in the public-key-encryption data- 
communication system, the root registration authority 
controls a plurality of system holders which provide or 
manage an infrastructure for distributing different con- 
tents or services, receives a public-key-certificate issu- 
ing request via one of the system holders from one of at 
least one service provider and at least one user terminal 
whch are under the control of the one system holder, 
and requests the public-key-certificate issuer authority 
to issue a public key certificate. 



[0028] In the pubfic-key-encryption data-communica- 
tion system, under the control of the system holder, the 
system holder may have contents creator which per- 
forms provision of contents by using a distribution infra- 

s structure for contents or a service provided or managed 
by the system holder, and the system holder may treat 
the contents creator as a subject to be certifk:ated. 
[0029] Preferably, in the public-key-encryption data- 
communk:ation system, a user device which is under the 

10 control of a plurality of different system holders control- 
led by a common publte-key-certifteate issuer authority 
has a public key of the common public-key-certifcate 
issuer authority. 

[0030] According to another aspect of the present in- 
is vention, the foregoing object is achieved through provi- 
sion of a public-key-encryption data-communteation- 
system fomning method including the steps of request- 
ing, by a subject to be certificated, a registration author- 
ity to issue a public key certificate, transfening. from the 
20 registration authority to a root registration authority cer- 
tifk^ating the registration authority, a publk:-key-certifi- 
cate Issuing request from the subject, and transferring, 
from the root registration authority to a public-key-cer- 
tificate issuer authority certificating the root registration 
25 authority, the publk;-key-certificate issuing request from 
the subject. 

[0031] Preferably, in the publtc-key-encryption data- 
communk»tion-system forming method, the root regis- 
tratton authority treats a plurality of registration author- 

30 [ties as subjects to be certificated, and each of the plu- 
rality of registration authorities treats, as a subject to be 
certificated, one of at least one service provider, at least 
one user terminal, and at least one user which are under 
the control of the registration authority. 

35 [0032] In the public-key-encryption data-communica- 
tion-system forming method, the registration authority 
or at least one service provider which is under the con- 
trol of the registration authority may apply, to a plurality 
of different services, a public key certificate correspond- 

40 ing to a subject to be certificated which is under the con- 
trol of the registration authority or of the at least one 
sen/ice provider which is under the control of the regis- 
tration authority. 

[0033] In the public-key-encryption data-communica- 
45 tion-system fomning method, the root registration au- 
thority may include, as one of a plurality of registration 
authorities as subjects to be certificated which are under 
the control of the root registration authority, a clearing 
center for executing settlement processing, and in 
50 processing using a public key certificate which is issued 
via the clearing center, settlement may be performed 
which relates to a servk:e provided by a registration au- 
thority other than the clearing center whk:h is under the 
control of the root registration authority or by at least one 
55 service provider which is under the control of the regis- 
tration authority other than the clearing center. 
[0034] In the public-key-encryption data-communica- 
tion-system forming method, the publte-key-certifk»te 
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issuer authority may hold a list of the correspondence 
among public keys and corresponding public key certif- 
icates, and the identifiers of subjects to be certificated 
for which the public key certificates are issued, and ei- 
ther the root registration authority or the registration au- 
thority may hold entity data which correspond to the sub- 
jects and whk;h include certification data on the sub- 
jecls- 

[0035} In the public-key-encryption data-communrca- 
tion-system forming method, the public key certificates 
may each include an electronk; signature field for an 
electronic signature of the public-key-certificate issuer 
authority, and a plurality of algorithms may be used as 
a signature algorithm for the electronic signature gener- 
ated in the electronic signature field, and the public key 
certificates may each include a field identifying the used 
algorithm. 

[0036] In the publk:-key-encryption data-communtea- 
tion-system forming method, in data transfer between 
the public-key-certifrcate issuer authority and the root 
registration authority, cross certification processing may 
be performed, and when the cross certification is estab> 
llshed, mutual data transfer may be executed. In data 
transfer between the root registration authority and the 
registration authority, cross certification processing may 
be performed, and when the cross certification is estab- 
lished, mutual data transfer may be executed, and in da- 
ta transfer between the registration authority and the 
subject, cross certification processing may be per- 
formed, and when the cross certification is established, 
mutual data transfer may be executed. 
[0037] In the public-key-encryption data-communtca- 
tion-system fomning method, between two among the 
public-key-certificate issuer authority, the root registra- 
tion authority, the registration authority, and the subject, 
data may be transferred in a form in which the data in- 
cludes a generated electronic signature of a data trans- 
mitting side. 

[0038] Preferably, in the public-key- encryption data- 
communication-system fomning method, at least one of 
the root registration authority and the registration au- 
thority possesses a revocation list concerning public key 
certificates corresponding to subjects whk:h are under 
the control of the at least one, executes the updating of 
the revocation list, and requests the public-key-certifi- 
cate issuer authority to perfomn data processing corre- 
sponding to the updating. 

[0039] In the publk:-key-enciyption data-communica- 
tion-system forming method, at least one of the root reg- 
istration authority and the registration authority may re- 
quest the issuance of a plurality of public key certificates 
corresponding to a plurality of services which are under 
the control of the one authority. 

[0040] In the public- key-encryption data-communfca- 
tion-system forming method, the public key certificate 
may include a common electronic signature of the pub- 
lic-key-certificate issuer authority which issues the pub- 
tic key certificate, and one of a root registration authority, 



a registration authority, a servk:e provider, and a user 
devk:e which perform processing for the verifk:ation of 
one public key certificate issued by the publk:-key-cer- 
tifk^ate issuer authority may perform offline processing 

s for the verification of different publk: key certificates is- 
sued by a single public- key-certificate issuer authority. 
[0041 J In the public-key- encryption data-communica- 
tion-system fomning method, the registration authority 
may be formed as a system holder as an authority whch 

10 provides or manages a distribution infrastructure for 
contents which are usable by a user terminal, contents 
for use in providing a servtee, or a sen/ice, and the sys- 
tem holder may control and may treat a service provider 
and the user terminal as subjects to be certificated. 

15 [0042] Preferably, in the public-key-encryption data- 
communk^ation-system forming method, the root regis- 
tration authority controls a plurality of system holders 
which provide or manage an infrastructure for distribut- 
ing different contents or sen^ices, receives a public-key- 

20 certificate issuing request via one of the system holders 
from one of at least one servk:e provider and at least 
one user terminal which are under the control of the one 
system holder, and requests the public-key-certiftoate 
issuer authority to issue a public key certificate. 

25 [0043] in the public-key-encryption data-communica- 
tion-systcm fomning method, under the control of the 
system holder, the system holder may have contents 
creator which performs provision of contents by using a 
distribution Infrastructure for contents or a service pro- 

30 vided or managed by the system holder, and the system 
holder may treat the contents creator as a subject to be 
certificated. 

[0044] Preferably, in the public-key-encryption data- 
communication-system forming method, a user devtoe 

35 Which is under the control of a plurality of different sys- 
tem holders controlled by a common public-key-certifi- 
cate issuer authority has a publk: key of the common 
public-key-certtficate issuer authority. 
[0045] The present invention enables control of a root 

40 registration authority to perform certificate acquiring 
processing that is conventk>nally performed by each 
service provider, and enables, for example, control of a 
clearing center (payment RA) to perform credit control 
processing (user's credit inquiry) with banking facilities 
such as banks, which is executed for settlement caused 
by the distribution of contents, without controlling a pro- 
vider that performs contents distribution to perform the 
processing. In other words, a service provider that starts 
a new electronic distribution business can entrust the 

50 management of Issuance of public key certificates to the 
root registration authority and the a public-key-certiti- 
cate issuer authority, and can entrust settlement 
processing to another registration authority which is un- 
der the control of the root registration authority, whereby 

ss the servrce provider enables provision of service that us- 
es a user public key certificate by only performing user 
managing operations. 

[0046] Also the user managing operations can be en- 
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trusted to the root registration authority. A registration 
authority as a service provider can be designed to re- 
ceive user information, revocation information, etc., 
from the root registration authority, as required. 
[0047] In the present invention, a public-key-certifi- s 
cate issuer authority perfonms issuance of public key 
certificates and management operations, and user man- 
agement, such as processing of registering users who 
use public key certificates, is entrusted to a root regis- 
tration authority, wherry the need for executing user io 
identifying operations dependent on service contents is 
eliminated. Also revocation list management is per- 
formed by the root registration authority, and the public- 
key-certificate issuer authority performs only processing 
for validating , invalidating, and deleting the certificate in is 
accordance with a request from the root registration au- 
thority. 

[0048] As described above, in the present invention, 
processes by a publrc-key -certificate issuer authority, a 
root registration authority, and a registration authority so 
are separately periormed, whereby, for each service, 
the identification of a user, and the issuance, registra- 
tion, and management of public key certificates are not 
required to be newly configured in the same way as in 
a conventional system, whereby a new service using a 2S 
public key and a publk; key certificate can be started by 
using existing data to configuring only necessary part. 
(0049] In the present invention, a public-key-certifi- 
cate issuer authority executes public-key-certifk:ate is- 
suing processing, and a root registration authority exe- 30 
cutes the management of users who use public key cer- 
tificates issued by the publrc-key-certificate issuer au- 
thority. Accordingly, a public key certif icate issued by the 
public-key-certiticate issuer authority can be used in 
common in various services provided by a plurality of 35 
service providers (registration authorities or servtee pro- 
viders managed by the registration authority), whereby 
a servbe provider that will provide a new service does 
not need to configure a registration authority function. 
£0050] In addition, since a public key certificate issued 40 
by a publlc>key-certificate Issuer authority is based on 
a standard fonmat, it is compatible with a public key cer- 
tificate issued by an existing registration authority, 
whereby it is possible to allow an existing system and 
the system of the present invention to exist in a mixed 
form. 

[0051] According to the present invention, processes 
by a public-key-certificate issuer authority, a root regis- 
tration authority, and a registration authority are sepa- 
rately performed, and for each service, the identification so 
of a user, and the issuance, registration, and manage- 
ment of public key certifksates are not required to be 
newly configured in the same way as in a conventional 
system, whereby a new service using a public key and 
a publk; key certificate can be started by using existing ss 
data to configuring only necessary part, whereby a load 
on the registration authority as in the conventional sys- 
tem can be reduced. 



[0052] According to the present invention, by forming 
a registration authority as a system holder that is an au- 
thority for providing or managing a contents or servrce 
distributing infrastructure for enabling provision of con- 
tents or services, certification and data communk;ation 
using a common public key certifcate can be executed 
between different infrastructures, and in a user device, 
the use of various services provided by different provid- 
ers, or cross certification processing with another user 
device can be executed using a common public key cer- 
tificate. 

[0053] Further objects, features, and advantages of 
the present invention will become apparent from the fol- 
lowing description of the preferred embodiments with 
reference to the attached drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0054] 

Fig. 1 is an illustration of an example of a public key 
certifteate; 

Fig. 2 is a block diagram showing an outilne of pub- 
lic-key-encryption data-communrcation system of 
the present invention; 

Fig. 3 is an illustration (example 1) of processes by 
a public-key-certificate issuer authority, a root reg- 
istration authority, and a subject to be certificated in 
a public-key-encryption data-communtoation sys- 
tem of the present invention; 
Fig. 4 is an illustration (example 2) of processes by 
a publk:-key-certificate issuer authority, a root reg- 
istration authority, and a subject to be certificated in 
a public-key-encryption data-communication sys- 
tem of the present invention; 
Fig. 5 Is an illustration of the data structure of a pub- 
lic-key-certificate issuer authority in a public-key- 
encryption data-communication system of the 
present invention; 

Fig. 6 is an illustration (No. 1} of the structure of a 
public key certificate in a public-key-encryption da- 
ta-communication system of the present invention; 
Fig. 7 is an illustration (No. 2) of the structure of a 
public key certificate in a public-key-encryption da- 
ta-communication system of the present invention; 
Fig. 8 is an illustration of a data structure in the da- 
tabase of a registration authority in a public-key-en- 
cryption data-communteation system of the present 
invention; 

Fig. 9 is an illustration (No. 1 ) of the structure of a 
revocation list in a pub lie- key-encryption data-com- 
munteation system of the present invention; 
Fig. 10 is an illustration (No. 2) of the structure of a 
revocation list in a publk:-key-encryptlon data-com- 
munication system of the present invention; 
Fig. 11 is a flowchart illustrating sign generating 
processing applicable to a public-key-encryption 
data-communication system of the present inven- 
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tion; 

Fig. 12 is a flowchart illustrating sign generating 
processing applicable to a public-key-encryption 
data-communication system of the present inven- 
tion; 5 
Fif. 13 is an illustration of cross certification 
processing applicable to a public-key/symmetric- 
key-encryption data-communication system of the 
present invention; 

Fig. 14 is an illustration of cross certification fO 
processing applicable to a public-lcey-encryption 
data-communication system of the present inven- 
tion; 

Fig. 15 is an illustration of terms for use in a public- 
key- encryption data-communication system of the 
present invention; 

Figs. 16A and 16B are illustrations of pre-reglstra- 
tion processing between a public-key-certificate is- 
suer authority and a registration authority in a pub- 
lic-key-encryption data-communfeation system of so 
the present invention; 

Fig. 17 is an illustration of pre- registration process- 
ing between a public-key-certificate issuer authority 
and a registration authority in a public-key-encryp- 
tion data-communication system of the present in- 

vention; 

Fig. 18 is an illustration of offline processing among 
a public-key-certrficate issuer authority, a registra- 
tion authority, and a user in a public-key-encryption 
data-communteation system of the present inven- 30 
tion; 

Fig. 1 9 is an illustration of processing among a pub- 
lic-key-certificate issuer authority, a root registration 
authority, a registration authority, and a user in a 
pubric-key-encryption data-communication system 
of the present invention; 

Fig. 20 is an illustration of key updating processing 
among a public-key-certificate issuer authority, a 
root registration authority, and a service provider in 
a public-key-encryption data-communication sys- 
tern of the present invention; 
Fig. 21 Is an illustration of key updating processing 
among a public-key-certificate issuer authority, a 
root registration authority, and a service provider in 
a public-key-encryption data-communication sys- 
tem of the present invention; 
Fig. 22 IS an illustration of key revocation process- 
ing among a public-key-certificate issuer authority, 
a root registration authority, and a user in a public- 
key -encryption data-communication system of the 50 
present invention; 

Fig. 23 is an illustration of key-revocation validating 
processing among a public- key-certificate issuer 
authority, a root registration authority, and a user in 
a public-key-encryption data-communication sys- ss 
tem of the present invention; 
Fig. 24 is an illustration of publk:-key-ceriificate de- 
leting processing among a public-key-cenificate is- 



suer authority, a root registration authority, and a us- 
er in a publrc-key-encryption data-communication 
system of the present invention; 
Fig. 25 is an illustration of a system holder and other 
authorities in a publte-key-encryption data-commu- 
nk:ation system of the present invention; 
Fig. 26 is an illustration of specific examples of a 
system holder and other authorities in a public-key- 
encryption data-communication system of the 
present invention; 

Fig. 27 is an illustration of an example in which a 
public key certiricate is used when a system holder 
does not have a hierarchcal structure with respect 
to a root registration authority; 
Fig. 28 is an illustration of an example in which a 
public key certificate is used when a system holder 
has a hierarchical structure with respect to a root 
registration authority; and 

Fig. 29 is an illustration of an example in which a 
public key certificate is used among a public-key- 
certificate issuer authority, a root registration au- 
thority, a registration authority, and a user in a pub- 
lic-key-encryption data-communication system of 
the present invention. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0055] Embodiments of the present invention are de- 
scribed below with reference to the drawings. 
[0056] In Fig. 2 is shown a schematic illustration of a 
data communication system and a data communication 
method that use public-key encryption. 
[0057) In Fig. 2, a shop 206, a terminal 207, a user 
device 208, and a user settlement organization 209 are 
subjects to be certificated, in other words, bodies that 
perform data transmission and reception based on pub- 
lic key encryption. Although Fig. 2 shows, as typical sub- 
jects to be certificated, one shop 206, one terminal 207, 
one user device 208, and one user settlement organi- 
zation 209, in general, many types of these exist, and 
other than these, various types of subjects to be certif- 
bated can exist. 

[0058] The shop 206, the terminal 207, the user de- 
vice 208. and the user settlement organization 209 as 
subjects to be certificated, which are under control of 
each registration authority (also indicated by "RA" in the 
accompanying drawings), request registration authori- 
ties (service provider RAs) 203 and 204, and a registra- 
tion authority (payment RA) 205 to issue public-key cer- 
tificates corresponding to public keys they use. 
[0059] The registration authorities 203, 204. and 205 
certificate subjects (entities and apparatuses participat- 
ing in services) in services, or certificate a payer for par- 
ticipators in the services (guarantee for payment). The 
registration authority 203, 204, and 205 also receive is- 
suing requests on public-key certificates corresponding 
to public keys used by the subjects (entities, apparatus- 
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es. and users participating in the services) in the serv- 
ices, and transfer them to a public-key-certificate issuer 
authority (also indicated by an "lA" in the accompanying 
drawings) 201 via a root registration authority (also in- 
dicated by a "root RA" in the accompanying drawings) 
202. The root registration authority 202 accepts the pub- 
lic-key-certificate issuing requests from the certificated 
registration authorities 203, 204, and 205. In other 
words, the root registration authority 202 accepts, as the 
public-key-certincate issuing requests, only requests 
from authorities certificated by the root registration au- 
thority 202. 

[0060] In Fig. 2, the registration authorities 203 and 
204 are, for example, service providers that perfonn pro- 
vision of services for distributing contents such as music 
data, image data, and game programs, and the regis- 
tration authority 205 is a clearing center that perfonns 
settlement processing on users' electronic money by 
performing data communication with the user settle- 
ment organization 209. These registration authorities 
shown in Fig. 2 are examples, and other than these, var- 
ious types of registration authorities that provide various 
services can exist. 

[0061] Each registration authority exists for each 
service (system), and the root registration authority 202 
exists as one that controls and certificates the registra- 
tion authorities. The root registration authority 202 is 
certificated by a public-key-certifk:ate issuer authority 
201 , which is described below. The registration author- 
ities 203, 204, and 205 are small-sized service bodies. 
When the service providers do not have registration au- 
thorities for them, the root registration authority 202 can 
function instead of them. 

[0062] The public-key-certificate issuer autiiority 201 
perfonns cross certification with the root registration au- 
thority 202 or the registration authority 203, 204 or 205, 
creates a public-key certificate based on a subject iden- 
tifier (ID) for identifying a subject as a public-key-certif- 
icate-issuance requesting body, a subject's public key, 
and other infomnation to be written in the public-key cer- 
tificate, which are transferred from the root registration 
authority 202 or each of the registration authorities 203 
to 205, and distributes the public-key certificate to the 
registration authorities 203 to 205. 
[0063] This makes it a condition that the root registra- 
tion authority 202 or each of the registration authorities 
203 to 205, which requests the publte-key-certificate is- 
suer authority 201 to issue a certificate, has been cer- 
tificated by tiie publte- key-certificate issuer authority. 
[0064] Also, in response to a request from the root 
registration authority 202 or each of the registration au- 
thorities 203 to 205, the public- key-cert if toate issuer au- 
thority 201 performs processing for responding to the 
updating, invalidation, and deletion of the public-key 
certificate, or to confirmation by the subject of the valid- 
ity of the public-key certificate. The public-key-certifi- 
cate issuer authority 201 is to be authorized by an ap- 
propriate legal organization, and is regarded as certifi- 



cated after being authorized. 

[0065] In Figs. 3 and 4 are illustrated processes in 
subjects to be certificated, such as the publk;-key-cer- 
tifbate issuer authority 201 , the root registration author- 
5 ity 202 or the registration authorities 203 to 205, the 
shop 206, the temninal 207, the user devk:e 208, and 
the user settlement organization 209. 
[0066] Fig. 3 shows a case in which the subjects to 
be certificated, such as the shop 206, the terminal 207, 
10 the user device 208. and the user settlement organiza- 
tion 209 themselves generate public keys and private 
keys that are applied to the public key encryption. Fig. 
4 shows a case in which the root registration authority 
202 or the registration authorities 203 to 205 each gen- 
is erate a public key and a private key. The service provid- 
ers 304 shown in Figs. 3 and 4 have no registration au- 
thority functions. 

[0067] Each process shown in Fig. 3 is described. The 
subject to be certificated 303 generates a public key and 
a private key that are applied to the public key encryp- 
tion, and requests the registration authority 302 to issue 
a certificate corresponding to the public key. A! this time, 
the subject to be certificated 303 transmits its ID and the 
public key. Its 10 is, for example, a user's own identifier, 
a user terminal identifier, or the like. When receiving the 
Information, the registration authority 302 verifies the 
subject to be certlfk;ated, and subsequently transfers 
the received subject ID and public key to the public-key- 
certificate Issuer authority 301 . The public-key-certifi- 
cate issuer authority 301 creates, based on the received 
subject ID and publk: key and on other information to be 
written in the public-key certificate, the publrc-key cer- 
tifkiate, and distributes the certificate to the registration 
authority 302 via the registration authority or the root 
registration authority. The registration authority 302 
transfers the publte-key certificate to the subject to be 
certificated 301 . 

[0068] When executing updating processing after 
generating a new public key and a new private key, the 
subject to be certificated 303 transmits the newly gen- 
erated pubric key to the registration authority 302 with 
its ID. After verifying the subject to be certificated 303, 
the registration authority 302 transfers the received sub- 
ject ID and public key to the public-key-certifk;ate issuer 
authority 301 , the public-key-certificate issuer authority 
301 creates a new public-key certificate based on the 
received subject ID and publk: key and on other infor- 
mation to be written in the public-key certifteate, and 
transmits the certificate to the subject to be certificated 
via the registration authority or the root registration au- 
thority. 

[0069] As shown In Fig. 3, the registration authority or 
the root registration authority 302 performs verification 
processing on the subject to be certificated, and the 
holding of apparatus information and user information, 
and manages revocation of an issue by the publk:-key- 
certificate issuer authority 301 . 
[0070] The public-key-certificate issuer authority 301 
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performs the management of the public key on the is- 
sued public-key certificate and the ID of the subject to 
be certificated, processing for issuing a public-key cer- 
tificate, processing for invalidating the issued public-key 
certificate, and processing for checking the validity of s 
the issued public- key certificate. 
[0071] As for revocation proceedings, the public- key- 
certificate issuer authority 301 executes, based on a re- 
quest from the registration authority or the root registra- 
tion authority 302, processing for invalidating the issued 
public-key certificate. The registration authority or the 
root registration authority 302 notifies the subject to be 
certificated 303 and the service provider 304, which 
needs revocation notification, of the revocation. The rev- 
ocation notification can be provided as difference data 
obtained by subtracting invalidator data from the revo- 
cation data by the registration authority, whteh manages 
the revocation list, or the registration authority 302. 
[0072] The subject to be certificated 303 can request 
the pubik:- key-certificate issuer authority 301 to verify 
whether its public key is usable, in other words, whether 
the public-key certificate Is valid. In this case, the subject 
to be certifk:ated 303 transmits its ID and the public key 
to the public-key-certificate issuer authority 301 , and va- 
lidity verification is performed based on public keys and 
the IDs of subjects to be certificated whkih are managed 
by the public-key-certificate issuer authority 301 . 
[0073] Fig. 4 shows the case in which the registration 
authority or the root registration authority 302 generates 
the public key and the private key. In Fig. 4, the public 
key and the private key, generated by the registration 
authority or the root registration authority 302 , are trans- 
mitted to the subject to be certificated 303, and the sub- 
ject to be certificated 303 stores them. The subsequent 
steps are similar to those in the processing in Fig. 3. 
[0074] Although the publk:-key-certificate revocation 
management in Figs. 3 and 4 is designed to be per- 
formed by the registration authority and the root regis- 
tration authority 302, the revocation management may 
be perfomried by the public-key-certificate issuer author- 
ity 301. 

[0075] In Fig. 5 are shown main items of data man- 
aged by the publk^-key-certificate issuer authority 301 . 
"RAID" is an identifier for a registration authority to which 
a servtee is provided. "ID" is an identifier for a subject to 
be certificated. "PUBLIC KEY" is a public key for the 
subject to be certificated, and "CERTIFICATE" is a pub- 
Ite-key certificate itself. "VALIDITY FLAG" is a flag indi- 
cating whether the public-key certificate Is valid. 
[0076] In Figs. 6 and 7 is shown a fonmat of a public- 
key certificate. This is an example based on Pubik: Key 
Certificate Fomnat X.509 Version 3. 
[0077] "version" indicates the version of a certifk^ate 
format. 

[0078] "Serial Number" indrcates the serial number of 
the public-key certificate whk;h is set by the publk:-key- 
certificate issuer authority. 

[0079] "Signature algorithm Identifier algorithm pa- 



rameter" is a field in which a signature algorithm of the 
public-key certificate and its parameters are recorded. 

The signature algorithm includes elliptk: curve encryp- 
tion and RSA. When elliptic curve encryption is applied, 
parameters and a key length are recorded, and when 
RSA is applied, a key length is recorded. 
[0080] "issuer* is a field in whk:h an issuer of the pub- 
lic-key certificate, namely, the name of the public-key- 
certiftcate issuer authority is recorded in a recognizable 
form (Distinguished Name). 

[0081] In "validity", a start date and time, and an end 
date and time are recorded which constitute a certificate 
validity period. 

[0082] In "subject", the name of a subject to be certif- 
icated, as a user, is recorded. Specincally, it is, for ex- 
ample, the ID of a user apparatus, the ID of a servk:e 
providing body, or the like. 

[0063] "subject Public Key Info algorithm subject Pub- 
lic key" is a field for storing a key algorithm and key in- 
formation as user's public key infonnation. 
[0084] These fields are included in public-key-certifi- 
cate fonmat X.509 Version 1 . The following are fields 
added in publk:-key-certificate format X.509 Version 3. 
[0085] "authority Key Identifier-key Identifier, authori- 
ty Cert issuer, authority Cert Serial Number" is infomia- 
tion for identifying a key to the public-key-certificate is- 
suer authority, and stores a key identification number 
(octal number), the name of the public-key-certificate is- 
suer authority, and an identification number. 
[0086] "subject key Identifier" stores an identifier for 
Identifying each key when a plurality of keys are certifi- 
cated in the public-key certificate. 
[0087] "key usage" is a field which designates a use 
of a key, and in which one of uses: (0) digital signature, 
(2) key encipherment, (1) non- repudiation, (3) data 
(message) encryption, (4) symmetric key transfer, (5) 
verifk»tion of a signature for certification, or (6) verif rca- 
tion of signatures on the revocation list. 
[0088] In "private Key Usage Period", the effective 
date of a private key retained by the user is recorded. 
[0089] In "certifk:ate Polbies", certificate issuance 
policies of the certificate authority, or the public-key cer- 
tif bate issuer authority and the registration authority are 
recorded. They mean, for example, a policy ID in ac- 
cordance with ISO/I EC 9384-1 , or a certificate standard. 
[0090] "policy Mapping" is a field used only when the 
CA (public-key-certificate issuer authority) is certificat- 
ed, and defines the policies of the public-key certificate 
issuer authority and the mapping of the policies to be 
certificated. 

[0091 ] "supported algorithms" defines the attribute of 
a directory (X.500). This is used such that, when another 
system with which communication is established uses 
directoiy information, its attribute is posted beforehand. 
[0092] "subject Alt Name" is a field in whk;h another 
name of the user is recorded. 

[0093] "issuer Alt Name" is a field in which another 
name of the certificate issuer is recorded. 
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[0094] "subject Directory Attribute" is a field in which 
user's arbitrary attributes are recorded. 
[0095] "basic Constrainr is a field for determining 
whether the public key to be certificated is for signing by 
the certificate authority (public-key-cenificate issuer au- s 
thority) or is of the user. 

[0096] "name Constraints permitted Subtrees" is a 
field indicating the effective range of a certificate used 
only when a subject to be certifk^ated is the certifk;ate 
authority (public-key-certificate issuer authority). 
[0097] "policy Constraints" describes a specifk: certif- 
icate policy ID corresponding to the remainder of certif- 
icate paths, and a prohibition policy map. 
[0098] "Certiffcate Revocation List Distribution 
Points" is a field to describe reference points of the rev- 
ocation list (see Fig. 9} that is used to confirm whether 
the certificate has been revoked when the user uses the 
certificate. 

[0099] "signature" is a field for a signature of a public- 
key -certificate issuer (public-key-certificate issuer au- 
thority). 

[0100] In Fig. B, the data structure of an entity data- 
base in the registration authorities in Figs. 3 and 4 is 
shown. The entity database is designed to manage sub- 
jects to be certificated. 

[01 01] "ID" is a field storing the identifiers of the sub- 
jects to be certificated. 

[0102] In "certificate data", information required for 
certificating the subjects to be cenificated, for example, 
user terminal IDs when user terminals are to be certifi- 
cated, etc., are recorded. 

[0103] In "certification results", last certification re- 
sults are recorded. 

[0104] In "revocation information", pointer information 
to the revocation list are recorded. 
[0105] In Figs. 9 and 10 are shown fomnat examples 
(based on X.509 V2) of the revocation lists. Fig. 9 shows 
common items, and Fig. 1 0 shows information managed 
by each certificate. Each item is described. 
[0106] 'signature Algorithm Identifier* describes a 
signature algorithm about a signature to be applied. For 
example, it is elliptic curve encryption or RSA. 
[0107] In "Issuer", the issuer of the revocation list is 
recorded. In the examples in Figs. 3 and 4, the name of 
the registration authority is recorded. 
[0108] In "This Update", the issuance date and time 
of the revocation list is recorded. 
[0109] In 'Next Update", the next date and time of the 
updating of the revocation list is recorded. 
[0110] In "Version", the version of the revocation list 
is recorded. 

[0111] "authority Key Identifier-key Identifier, authori- 
ty Cert Issuer, authority Cert Serial Number" is informa- 
tion for identifying a key to the publk:-key-certificate is- 
suer authority, and stores a key identification number 
(octal number), the name of the public-key-certiffcate is- 
suer authority, and a certificate number. 
[0112] In "CRL Number*, the issuance serial number 



of the revocation list is recorded. 
[01 13) In revocation list information ("Issuing distribu- 
tion point"), various types of information on the revoca- 
tion list are recorded: a distributor name ("Distribution 
point"), information ("only contains user certs') on 
whether the revocation list is used dedk^atedly for sub- 
scriber revocation, infonmation on whether the revoca- 
tion list is used dedicatedly for revocation of the certifi- 
cate by the certificate authority (in this embodiment, the 
public-key-certifteate issuer authority), and information 
fonly some reasons") on whether there are other revo- 
cation reasons, and whether the revocation list is an in- 
direct revocation list ("indirect CRL"). The indirect revo- 
cation list ("indirect CRL") is a form in which the man- 
agement of information on revocation reasons and the 
management of the revocation list are perfomned by 
separate organizations. For example, in a case in whk;h 
the root registration authority issues the revocation list, 
and the publk:-key-certificate issuer authority manages 
the public-key-certificate issuer authority, the form is de- 
fined as the indirect revocation list (indirect CRL). In this 
case, revocation information storing points, for example, 
data that represent lA identifiers are stored. According 
to the construction of the present invention, the revoca- 
tion list is generated as the indirect revocation list (indi- 
rect CRL), and the infonmation on revocation reasons is 
managed not by a revocation list issuer but by the public- 
key-certiflcate issuer authority. 
[0114] In a CRL identifier difference ("Delta CRL Indi- 
cator"), data on whether the revocation list Is distributed 
as a difference list are recorded. The difference list is a 
list structure in which public-key information on deter- 
mined revocation, extracted from public-key infonmation 
on revocation options, is designed to be providable to a 
related provider. 

[0115] Fig. 10 is an illustration of information man- 
aged by each certificate. 

[0116] In "certificate Serial Number", a certificate 
number is recorded. 

[0117] In "Revocation Date", the date and time of ac- 
ceptance of an application for revocatton is recorded. 
[0118] The fields In so far are fields defined In version 
1 , and the following ones are fields defined in Version 2. 
[0119] "Reason code' is a field to describe revocation 
reasons. Revocation reasons are as follows: 0: reason 
unknown; 1 : subscriber compromised; 2: CA (public- 
key-certifk»te issuer authority) key compromised; 3: 
certificate information has changed; 4: the certificate 
has got replaced; 5: suspension of use; 6: temporary 
suspension of use; and 7: release of temporary suspen- 
sion state. 

[0120] 'i-lold instruction code" describes a method of 
coping with the temporary suspension of use. 
[0121] 'invalidity date" describes a date and time at 
which the private key may have been damaged. 
[0122] "certifk^ate issuer" describes the name of the 
certificate authority. However, in the case of the indirect 
revocation list, revocation information is not managed 
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by the revocation list issuer authority. Accordingly, a 
designated revocation information management CA (e. 
g., the public-key-certificate Issuer authority) Is used to 
make a detour, in other words, a pointer to the (A is set. 
[0123] "signature" is a signature of the revocation list 
issuer. 

[01 24] An electronic signature and cross certification 

processing, used In the public-key-certificate issuing 
system and data communication method of the present 
invention, are described. After describing the electronic 
signature and cross certification processing, details of 
specific processing in the public-key-certificate issuing 
system of the present invention are described below 
with reference to the drawings. 

Electronic Signature 

[0125] A method of generating an electronic signature 
by using the public key encryption is described below 
with reference to Fig. 11 . The process shown in Fig. 11 
is a process flow of generating electronic signature data 
using EC-DSA ((Elliptic Curve Digital Signature Algo- 
rithm), IEEE P1363/D3). Here, an example that uses the 
Elliptic Curve Cryptography (hereinafter referred to as 
the ECC) as the public key encryption is described. In 
the data processing according to the present invention, 
In addition to the elliptic curve cryptography, for exam- 
ple, the RSA encryption ((RIvest, Shamir, Adieman), 
etc., (ANSI X9.31)) in a similar public key encryption 
may be used. 

[0126] The steps in Fig. 11 are described. In step SI , 
a characteristic is represented by p, coefficients of an 
elliptic curve (elliptic curve: y2 = + ax + b) are repre- 
sented by a and b, a base point on the elliptic curve Is 
represented by G, an order of G is represented by r, and 
a private key is represented by Ks (0 < Ks < r). In step 
S2, a hash value of message M is calculated, and it is 
assumed that f = Hash(M). 

[0127] Here, a method of finding a hash value by us- 
ing the hash function Is described. The hash function Is 
a function in which an input message is compressed into 
data having a predetermined bit length and the data is 
output as a hash value. The hash function has features 
in that it is difficult to predict an input from a hash value 
(output), In that many bits of the hash value are changed 
when one bit of data input to the hash function, and in 
that it is difficult to find out different input data having the 
same hash value. As the hash function, MD4, MD5, 
SHA-1, or the like, nnay be used, or DES-CBC may be 
used. In this case. MAC (check value: corresponding to 
ICV) that is used as a final output value becomes a hash 
value. 

[0128] Subsequently, in step S3, a random number u 
(0 < u < r) is generated, and in step S4, coordinates V 
(Xv. Yv) that is obtained by multiplying the base point by 
u times is cateulated. Addition and doubling on the ellip- 
tic curve are defined as foltows: 



If P = (Xa. Ya), Q = (Xb. Yb), and R = (Xc. Yc) = P 
4- Q. when P Q (addition), 

Xc = X2 - Xa - Xb 
5 Yc = X. X (Xa - Xc) - Ya 

X = (Yb - Ya)/(Xb - Xa) 

when P = O (doubling), 

10 Xc = X2 - 2Xa 

Yc = X X (Xa - Xc) - Ya 
X = (3(Xa)2 4- a)/(2Ya) 

[0129] Using these, a value that is u times the point 
IS G is calculated (although the speed is slow, the following 
is used as the most understandable operation method: 
G, 2 X G, and 4 X G are calculated, u is expanded in 
binary number, and corresponding 2* x G (a value ob- 
tained by doubling G i times (i is a bit position counted 
20 from the LSB of u)) is added to a position having 1 . 
[0130] In step S5, c = Xvmod r is calculated, and in 
step S6, it is determined whether this value is zero. If 
this value is not zero, d = [(f -i- cKs)/u) mod r is calculated 
in step 87, and it Is determined in step 38 whether d is 
25 zero. If d Is not zero, in step S9, c and d are output as 
electrons signature data. If it is assumed that r has a bit 
length of 1 60 bits, the electrons signature data has a bit 
length of 320 bits. 

[0131] If c is zero in step S6, the process proceeds 
30 back to step S3, and generates a new random number 
again. Similarly, if d is zero in step SB. the process pro- 
ceeds back to step S3, and generates a random number 

again. 

[0132] Next, a method of verifying the electronic sig- 
35 nature by using the public key encryption is described 
below with reference to Fig. 12. In step S11, a message 
is represented by M, a characteristk: is represented by 
p, coefffeients of an elliptic curve (elliptte curve: y2 = x^ 
+ ax + b) are represented by a and b, a base point on 
40 the elliptic curve is represented by G, an order of G Is 
represented by r, and G and Ks x G are used as a public 
key (0 < Ks < r). In step SI 2, it is detenmined whether 
electrons signature data c and d satisfy 0 < c < r and 0 
< d < r. If these conditions are satisfied, in step 813, a 
45 hash value of the massage M is calculated, and it is as- 
sumed thatf = Hash(M). Next. In step SI 4, h = 1/dmod 
r is calculated, and In step S15, hi = fh mod rand h2 = 
ch mod r are calculated. 

[0133] In step 816, using the already calculated h1 
50 and h2, point P - (Xp, Yp) = hi x G + h2 Ks x G is cal- 
culated. Since an electronic signature verifier knows 
public keys G and Ks x G, the verifier can perform cal- 
culation of multiplying a point on the elliptic curve by a 
scalar times, similariy to step S4 In Fig. 1 1 . In step Si 7, 
55 it is determined whether the point P is a point at infinity. 
If the point P is not a point at infinity, the process pro- 
ceeds to step 818 (actually, determination on the point 
at infinity can be performed in step 81 6. In other words. 
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addition for P = (X, Y) and Q = (X, -Y) makes It impos- 
sible to calculate X, and it is found that P + Q is a point 
at infinity). In step SI 8, Xp mod r is calculated, and is 
compared with electronic signature data c. When these 
values are finally identical, the process proceeds to step 

51 9, and determines that the electronic signature is cor- 
rect. 

[0134] If the process has determined that the elec- 
tronic signature is correct, the data is not manipulated, 
and it is found that a person who retains a private key 
corresponding to the public key has generated the elec- 
tronic signature. 

[0135] If the electronic signature data c or d does not 
satisfy 0<c<rorO<d<r, the process proceeds to 
step S20. Also if the process has determined in step SI 7 
that the point P is a point at infinity, it proceeds to step 

520. Also If the value of Xp mod r is not coincident with 
the electronk: signature data c, the process proceeds to 
step S20. 

[01 36J If the process has determined in step S20 that 
the electronic signature is not correct, it is found that the 
data is manipulated and it is found that a person who 
retains a private key conre^onding to the public key has 
not generated the electronic signature. 

Cross Certification 

[01 37] Between two means executing data transmis- 
sion and reception, after both verifies each other as a 
correct data communk:ator, both transfer necessary da- 
ta to each other. Verifrcation processing on whether both 
means are correct data communicators Is cross certifi- 
cation processing. It is one preferred data transfer meth- 
od that, after the generation of a session key is per- 
fomied in the cross certification processing, data trans- 
mission is performed executing encryption processing 
with the generated session key as a public key. 
[01 38] Cross certification using the public key encryp- 
tion is described below with reference to Fig. 13. In Fig. 
13. DES is used as the public key encryption, but a sim- 
ilar type of public key encryption may be used. 
[01 39] At first, "B" generates a 64-bit random number 
Rb, and transmits Rb and ID(b) that is an ID of itself to 
A. When receiving theses, "A" generates another 64-bit 
random number Ra, and uses key Kab in the CBC mode 
of DES to encrypt the data in the order of Ra, Rb, and 
ID(b), and sends the encrypted data back to B. 
[01 40] When receiving the encrypted data, B uses the 
key Kab to decr^t the received data. In a method of 
encrypting the received data, first, by using the key Kab 
to decrypt a ciphertext El, the random number Ra is 
obtained. Second, by using the key Kab to decrypt a ci- 
phertext E2, and performing exclusive logical addition 
of the decrypted result and El , Rb is obtained. Finally, 
by using the key Kab to decrypt a ciphertext E3, and 
performing exclusive logical addition of the decrypted 
result and EZ, ID(b) is obtained. Among Ra. Rb, and ID 
(b) obtained as described above, B verifies whether Rb 



and ID(b) are kientteat to those transmitted by B. if the 
verification is affirmative, B certiricates that A is correct. 
[0141] Next, B generates a Session Key (hereinafter 
referred to as a Kses) that is used after the certification 
5 (the generating method uses a random number). B uses 
the key Kab in the CBC mode of DES to encrypt Rb, Ra, 
and Kses in the order given, and sends the encrypted 
data back to A. 

[0142] When receiving these, A uses the key Kab to 
10 decrypt the received data. Since a method of decrypting 
the received data is similar to that performed by B, its 
details are omitted. Among Rb, Ra, and Kses obtained 
as described above, A verifies whether Rb and Ra are 
identical to those transmitted by A. If the verification Is 
'5 affirmative, A certifies that B is correct. After both certif- 
icate each other, the session key Kses is used as a sym- 
metric key for secret communk^ation after the certifica- 
tion is performed. 

[0143] If incorrectness and Inconsistency are found 

20 when verifying the received data, the cross certifrcation 
is regarded as falling, and processing is discontinued. 
[0144] Next, a cross certification method using a 
160-bit elllptk: curve encryption as a publb-key encryp- 
tion method is described with reference to Fig. 14. In 

25 Fig. 14. ECC is used as a public-key encryption method, 
but a similar public-key encryption method may be used 
as described above. Also the key size may not be 1 60 
bits. In Fig. 14, first, B generates and transmits 64-bit 
random number Rb to A. When receiving It, A newly gen- 

30 erates 64-bit random number Rb and random number 
Ak smaller than characteristic p. A finds point Av = Ak x 
G, which is Ak times the base point G, and generates 
and sends electronic signature A.Sig corresponding to 
Ra, Rb, and Av (X coordinate and Y coordinate) back to 

35 B, with a public key certificate of A. Here, Ra and Rb 
each have 64 bits, and the X coordinate and Y coordi- 
nate of Av each have 160 bits. Thus, an electronk: sig- 
nature corresponding to a total of 448 bits is generated. 
Since the electronic signature generating method has 

40 been described with reference to Fig. 11 , its details are 
omitted. 

[0145] When using a public key certificate, the user 
uses a public key of the public-key-certif »ate issuer au- 
thority 410, which is retained by the user, to verify an 

45 electronic signature of the public key certificate. After 
succeeding in the verifteation of the electro nk: signature, 
the user extracts the public key from the publk: key cer- 
tifk:ate, and uses the obtained public key. Accordingly 
all users who use the public key certificate must retain 

50 public keys of a common publk:-key-certificate issuer 
authority. Since the electrons signature verifying meth- 
od has been described with reference to Fig. 12, its de- 
tails are omitted. 

[01 46] Ref enring back to Fig. 2, the description is con- 
55 tinued. When receiving the public key certificate of A, 
Ra, Rb, Av, and the electronic signature A.Sig, B verifies 
whether Rb transmitted from A is identk:al to that sent 
by A. As a result, if the verifteatlon is affirmative, B uses 
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a public key of the certificate authority to verify the elec- 
tronic signature in the public key certifk;ate of A, and 
extracts the A's public key. B uses the extracted public 
key of A to verily the electronic signature A.Sig. Since 
the electronic signature verifying method has been de- 
scribed with reference to Fig. 12. its details are omitted. 
After succeeding in the verification of the electronic sig- 
nature, B certifies that A is correct. 
[0147] Nest, B generates random number Bk smaller 
than characteristic P. B finds point Bv = Bk x G, which 
is a value obtained by multiplying base point G by Bk 
times, and generates and sends electrons signature B. 
Sig that corresponds to Rb. Ra, and Bv (X coordinate 
and Y coordinate) back to A, with a public key certifwate 
of B. 

[0148] When receiving the public key certificate of B, 
Rb, Ra, Av, and the etectronk: signature B.Sig, A verifies 
whether Ra transmitted by B is identical to that gener- 
ated by A. As a result, if both are identteal, A uses the 
public key of the certificate authority to verify the elec- 
tronk: signature in the public key certificate of B, and 
extracts the publk: key of B. A uses the extracted public 
key of B to verity the electronic signature B.Sig. After 
succeeding in the verification of the electronic signature, 
A verifies that B is correct. 

[0149] When both succeed In certification, B cak:u- 
lates Bk x Av (although Bk is a random number, it is 
required to perform multiplication by a scalar times since 
Av is a point on the elliptic curve). A cafculates Ak x Bv, 
and the lower 64 bits of the X coordinates of these points 
are used as a session key for subsequent communrca- 
tion (in a case in which the symmetric encryption Is de- 
signed to symmetric encryption using a 64-bit key 
length). Definitely, the session key may be generated 
from the Y coordinates, and the lower 64 bits may not 
be used. In secret communication after the cross certi- 
fication, in addition to session-key encryption, an elec- 
trons signature may be put on transmission data. 
[0150] When incorrectness and Inconsistency are 
found In the verification of the electrons signature and 
the verification of the received data, the cross certifica- 
tion is regarded as failing, and the processing is discon- 
tinued. 

[0151] In the above-described cross certification 
processing, the generated session key Is used to en- 
crypt transmission data, and mutual data communrca- 
tion is executed. 

[0152] In Fig. IS is shown descriptions of tenms that 
are used in the following description and that are related 
to the public-key-certificate issuing system and the data 
communication method of the present invention. These 
are briefly described. A key is represented by K, P is 
added as a suffix to mean a public key, S is added as a 
suffix to mean a private key, and an owner identifier (e. 
g., a) is added. A session key that is generated in cross 
certification for use in encryption and decryption 
processing is represented by Ks. A public key certifcate 
of B. issued by A, is represented by A-B-. Concerning 



the ertciyption of data, for example, data encrypted us- 
ing the session key Ks is represented by EKs(data). Sim- 
ilarly, decrypted data is represented by DKs(data). Con- 
cerning signature processing, for example, data signed 

5 using the private key Ksa of A Is represented by {data} 
Sig-Ksa. Concerning encrypted signed data, what is ob- 
tained by using the session key Ks to encrypt "datallsig- 
nature" that is generated by signing data using the pri- 
vate key Ksa of A is represented by EKs({data)Sig-Ksa). 

10 [0153] Figs. ISA and 16B show processes executed 
in the process of registering the root registration author- 
ity. Fig. 16A shows an online case, and Fig. 16B shows 
an offline case. Processing order is indicated by num- 
bers. The online case in Fig. 16A is described. In the 

15 online case, between the root registration authority 1 601 
and the public-key-certificate issuer authority 1 602, the 
cross certification described with reference to Figs. 13 
and 14 is executed using a pair of public keys of the root 
registration authority which are transferred to the root 

20 registration authority beforehand via another route 
which is not shown, whereby both recognizes each oth- 
er for communication, and the session key Ks is gener- 
ated. 

[01 54] After thecross certification processing ends, the 
root registratton authority 1601 generates its pubte key 
and private key, and requests the publte-key-certificate 
issuer authority 1602 to issue a publrc key certificate cor- 
responding to the generated public key. The request for 
Issuing the certificate is perfomned such that the root reg- 

30 istration authority 1 601 transfers, to the publk:-key-certif- 
feate issuer authority 1602, EK»({RootRAID, Kp- 
RootRA')sig.KsRooiRA) that is data encrypted using the 
session key Ks for the identifier RootRAID of the root reg- 
istration authority 1 601 and the public key KpRootRA* of 

35 the root registration authority 1 601 . 

[0155] After decrypting the received encrypted data 
E^^,({RootRAID, KpRootRA')sig.KsH«rtRA). verifying 
the signature, the publk:-key-certificate issuer authority 
1 602 stores the public key KpRootRA' of the root regis- 

40 tration authority 1601 as data to be managed in a data- 
base. In other words, the pubik:-key-certificate issuer 
authority 1602 stores it as data in the database previ- 
ously described with reference to Fig. 5. 
[0156] In response to the certlfbate Issuing request 

45 from the root registration authority 1601 . the public-key- 
certifk^te issuer authority 1 602 generates the publk: key 
certiftoate. This is a public key certificate in accordance 
with the fomats in Rgs. 6 and 7. The public-key-certifi- 
cate issuer authority 1602 stores the generated publk: 

so key certifkate in the database for management (see Fig. 
5). Also, by signing the publk: key certifteate of the root 
registration authority 1601 which is issued by the public- 
key-certificate issuer authority 1602= namely, 
IA«RootRA» by using the private key KsIA of the publk:- 

55 key-certificate issuer authority 1 602, and encrypting it us- 
ing the session key Ks generated in the previous cross 
certification, the publk:-key-certificate issuer authority 
1602 generates the data EKs({IA«'RootRA»}s,g.K,|A). and 
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transmits the generated data to the root registration au- 
thority 1601 . The root registration authority 1601 stores 
the transmitted data. Secret information both have in 
common beforehand may be a symmetric key. In this 
case, SigKsRootRA is an MAC value with the symmetric 
key used. 

[0157] When the publk:- key-certificate issuer author- 
ity 1 602 uses the registration authority to directly issue 
the public key certificate without using the root registra- 
tion authority, the processing is such that the root reg- 
istration authority 1601 in Fig. 16 is replaced by the reg- 
istration authority. 

[0158] Fig. 16B shows an offline case in which the 
registering process is executed via a storage medium, 
for example, a DVD, a CD. a memory card, etc. In the 
offline process case, the processing is executed by stor- 
ing, in a storage medium, the information described 
about the offline process. 

[01 59] Fig. 1 7 shows an example of a procedure per- 
fomned when a registration authority 1701 perfonns the 
issuance of a public key certificate in a case In which, 
under management by the root registration authority 
1 601 , there is the registration authority 1 701 , which op- 
erates as, for example, a service provider providing a 
servce of distributing contents such as music data and 
image data, or as a service provider performing 
processing for electronic money settlement. The exam- 
ple is described in the order of the procedure. 
[01 60] Fl rst, cross certif toation processing is executed 
between the registration authority 1 701 and the root reg- 
istration authority 1601. This is executed using, for ex- 
ample, cross certification keys (corresponding to the key 
Kab described with reference to Fig. 13) that are stored 
beforehand the memories of the registration authority 
1701 and the root registration authority 1601 . 
(01 61 ] Second, the registration authority 1 701 signs the 
identifier SPID of the registration authority 1701 using its 
private key K^gp, generates the data EK8({SPID}sig.KsSp) 
by performing encryption using the session key Ks gener- 
ated in the cross certifk:ation, and transmits the generated 
data to the root registration authority 1 601 . After using the 
session key Ks to decrypt the received data and verifying 
the signature, the root registration authority 1601 recog- 
nizes the signature and executes the signing of the recog- 
nition result, and perfonns encryption using the session 
key and executes recognition responding to the registra- 
tion authority 1701. 

[01 62] When receiving the recognition response from 
the root registration authority 1 601 , the registration au- 
thority 1701 generates its public key and private key, 
signs the public key KpSP' using its private key, and en- 
crypts the signed public key using the session key to 
generate the data E,^s({KpSp'}sig,KsSp)- registration 
authority transmits the generated data to the root regis- 
tration authority 1601 . When receiving the data, the root 
registration authority 1601 executes the requesting of 
the public-key-certificate issuer authority 1602 to issue 
a public key certificate of the registration authority 1 701 . 



Cross certification processing is performed between the 
root registration authority 1601 and the public- key-cer- 
tifbate issuer authority 1 602. 

[0163] When certification is established in the cross 
5 certification processing, the root registration authority 

1601 executes the signing of the identifier SPID of the 
registration authority 1 701 and the public key KpSp of 
the registration authority 1 701 by using the private key 
of the root registration authority 1601. generates E^j 

10 ({SPID. KpSP')sig.KsRootSp) by perfonming encryption 
using the session key generated in the cross certifica- 
tion, and transmits the generated data to the public- 
key-certificate issuer authority 1602. 
[0164] The publrc-key-certificate issuer authority 

15 1602 decrypts the received data Eks((SPID, Kp- 
SP'}sig.KsRootSp)' stores the public key KpSP of the 
registration authority 1 701 as management data in a da- 
tabase. In other words, it is stored as data in the data- 
base described with reference to Fig. 5. 

20 [01 65] The publfc-key-certrfcate issuer authority 1 602 
further generates a public key certificate of the registra- 
tion authority 1701 . This is a public key certificate in ac- 
cordance with the fomnats in Figs. 6 and 7. The publk;- 
key-oertificate issuer authority 1 602 stores the generated 

25 publk: key certificate in the database for management 
(see Fig. 5). The public-key-certificate Issuer authority 

1602 also uses the private key KsIA of the public-key- 
certificate issuer authority 1 602 to sign the publk: key cer- 
tificate of the registration authority 1 701 , namely, IA«SP», 

30 which is issued by the public-key-certificate issuer au- 
thority 1 602, generates the data EKs({'A«SP»)sjg.KsiA) 
perfomning encryption using the session key Ks2 gener- 
ated in the cross certification processing, and transmits 
the generated data to the root registration authority 1 601 . 

35 The root registration authority 1 601 verifies the signature, 
uses its private key to perform sign the received data, and 
encrypts the signed data using a session key (the session 
key generated in the cross certification processing exe- 
cuted between the registration authority 1701 and the 

40 root registration authority 1 601 ). The root registration au- 
thority 1 601 transmits the encrypted data to the registra- 
tion authority 1 701 . After using the session key to decrypt 
the received data, and verifying the signature, the regis- 
tration authority 1701 stores the certificate. 

45 [01 66] In the above -described procedure, by omitting 
(5) the key generating process, the key that is embed- 
ded in a device of the registratkin authority 1701 may 
be used as a publk: key. In addition, by perfomriing cross 
certification in which an initially embedded key is used 

50 as a symmetric key, a signature on (2) the data may be 
an MAC generated using the symmetric key. 
[0167] Fig. 18 illustrates a construction in which the 
process, which is described with reference to Fig. 1 7, of 
issuing the public key certifk:ate of the registration au- 

55 thority 1701 is executed In offline. The data transmitted 
between the authorities are processed such that they 
are exchanged using various storage media, for exam- 
ple, a DVD. a CD, a memory card, etc. In the offline proc- 
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ess case, the information that is described about the of- 
fline process is stored in a storage medium for process- 
ing. 

[0168] Fig. 19 shows an example of a procedure per- 
fomned when a user 2001 (including a shop or the like) 
perfomns the issuance of a public key certificate in a 
case in which, under management by the registration 
authority 1701, there is a user who uses contents, a 
shop that sells contents: or the like. The example is de- 
scribed in the order of the procedure. 
[0169] In a device of the user 2001, the public key 
KpUD and private key KsUD of the user device, the pub- 
lic key KpRA of the registration authority 1701, and the 
public key KplA of the public-key-certificate issuer au- 
thority 1602 are embedded as initial embedded keys, 
for example, in a memory in an SAM (secure Application 
module). 

[01 70] First, the user 2001 and the registration author- 
ity 1701 execute cross certification processing, and a 

session key is generated in the cross certification 
processing. This is perfomied using KpUD stored be- 
forehand In the user 2001 . 

[0171] Next, the user 2001 uses its private key K^yg 
to sign the identifier SAMID of the user 2001 , generates 
the data Ek8({SPID)s^ksia) by perfomriing encryption 
using the session key Ks generated in the cross certifi- 
cation, and transmits the generated data to the root reg- 
istration authority 1701 . The registration authority 1 701 
uses the session key Ks to decrypt the received data, 
recognizes the identifier SAMID, and executes signing 
processing on the recognition result. The registration 
authority 1701 also uses the session key to perform en- 
cryption, and executes recognition responding to the us- 
er 2001. 

[0172] When receiving the recognition response from 
the registration authority 1701 , the user 2001 generates 
its public key and private key, uses its private key KsUD 
to sign the public key KpUD*. and generates the data 
EKs({KpUD}sin.KsiA) performing encryption using the 
session key. The user 2001 transmits the generated da- 
ta to the registration authority 1 701 . 
[0173] When receiving the data, the registration au- 
thority 1701 executes cross certification with the root 
registration authority 1601, and generates a session 
key. Next, the registration authority 1 701 uses its private 
key KsRA to sign the identifier SAMID and public key 
KpUD of the user 2001 , uses the session key Ks2 to 
encrypt the signed keys, and transmits the encrypted 
keys to the root registration authority 1601 . 
[0174] The root registration authority 1601 performs 
decryption and verification processes by using the data- 
related session key transmitted from the registration au- 
thority 1 701 , and executes the requesting of the public- 
key-certificate issuer authority 1 602 to issue a certificate 
of the user 2001. In addition, the root registration au- 
thority 1 601 and the public-key-certificate issuer author- 
ity 1602 execute cross certification processing. 
[0175] When certifteation is established in the cross 



certification processing, the root registration authority 

1 601 uses the private key of the root registration author- 
ity 1601 to execute the signing of the identifier SAMID 
and publk: key KpUD of the user 2001, and generates 

5 Ek5({SAMID. KpUD)sig.KsRootsp) by performing encryp- 
tion of the keys using the session key generated in the 
cross certification. The root registration authority 1601 
transmits the generated data to the public-key-certifi- 
cate issuer authority 1602. 

10 [0176] After decrypting the received data Eks({SA- 
MID, KpUD)sig.K5RootSp)' verifying the signature, 
the publk:-key-certificate issuer authority 1602 stores 
the public key KpUD of the user 2001 as management 
data in the database. In other words, the publk;-key-cer- 

15 tificate issuer authority 1 602 stores it as data in the da- 
tabase described with reference to Fig. 5. 
[0177] The publk:- key -certificate issuer authority 

1 602 further generates a public key certificate of the us- 
er 2001 . This is a public key certifk^ate in accordance 

20 with the fonnats in Figs. 6 and 7. The publlc-key-certif- 
icate issuer authority 1 602 stores the generated public 
key certificate in the database for management (see Fig. 
5). The public-key-certificate issuer authority 1602 also 
uses the private key KsIA of the public-key-certificate 
2s issuer authority 1 602 to sign the publk: key certificate, 
namely, lA-UD* of the user 2001, whk^h is issued by 
the publkj-key-certifk:ate issuer authority 1602, and 
generates the data EKs3({IA«UD»}sjg.K»iA) by perfom)- 
ing encryption using the session key Ks3 generated in 
30 the cross certification processing. The public-key-certif- 
k;ate issuer authority 1 602 transmits the generated data 
to the root registration authority 1 601 . The root registra- 
tion authority 1601 verifies the signature, and uses its 
private key to sign the received data. The root registra- 
rs tion authority 1601 encrypts the signed data by using 
the session key (the session key generated in the cross 
certification processing executed between the registra- 
tion authority 1701 and the root registration authority 
1 601), and transmits the encrypted data to the reglstra- 
40 tion authority 1701 . The registration authority 1 701 fur- 
ther uses its private key to sign the received data, en- 
crypts the signed data by using the session key (the ses- 
sion key generated in the cross certification processing 
executed between the user 2001 and the registration 
45 authority 1 701 ). and transmits the encrypted data to the 
user 2001 . After decrypting the received data using the 
session key, and verifying the signature, the user 2001 
stores the certificate. 

[0 1 78] I n the above-described p rocedure, by om itting 
so (5) the key generating process, the key embedded in 
the device of the user 2001 may be directly used as a 
public key. In addition, by perfonrting cross certification 
in whk:h an initially embedded key is used as a symmet- 
ric key, a signature on (2) the data may be an MAC gen- 
55 erated using the symmetric key. 

[0179] Fig. 20 is an illustration of a procedure or up- 
dating processing in whch a service provider as ttie reg- 
istration authority 1 701 under management by the root 
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registration authority 1601 generates a new public key 
and private key and perfomns issuance of a certiricate 

of the newly generated public key. 
[0180] The registration authority 1701 generates a 
new public key and private key Next, the registration 
authority 1 701 and the root registration authority 1 601 
execute cross certificatton processing. This can be ex- 
ecuted as cross certification processing using the 
present keys (the public key and the private key at the 
present time (before updating)), i.e.. processing using 
asymmetric key encryptk>n described with reference to 
Fig. 14. 

[0181] Next, the registration authority 1701 uses its 
private key to sign the public key KpSP' that is newly 
generated by the registration authority 1701 . generates 
the data E,(s({'^^'^'}sig KsSp) performing encryption 
using the session key generated in the cross certifk:a- 
tion processing, and transmits the generated data to the 
root registration authority 1601 . When receiving the da- 
ta, the root registration authority 1 601 executes revoca- 
tion checking. The revocation checking Is executed as 
the writing of publk^ key data to be revoked in the revo- 
cation list described with reference to Figs. 9 and 10. 
[0182] The root registration authority 1 601 further ex- 
ecutes the requesting of the public-key -certificate issuer 
authority 1 602 to issue a certificate of the registration 
authority 1 701 . In addition, the root registration authority 
1601 and the public-key-certificate issuer authority 1 602 
execute cross certiftcatlon processing. 
[0183] When certification is established In the cross 
certification processing, the root registration authority 

1 601 uses the private key of the root registration author- 
ity 1 601 to sign the identifier SPID of the registration au- 
thority 1 701 and the public key KpSp of the registration 
authority 1701 , generates E^({SPID, KpSp'}sig.KsRoot- 
sp) by performing encryption using the session key gen- 
erated in the cross certification processing, and trans- 
mits the generated data to the public-key-certificate is- 
suer authority 1602. 

[0184] After decrypting the received data Eks2({SPID, 
KpSp')sig.KsRootsp)' verifying the signature, the pub- 
lk:-key-ceitificate issuer authority 1 602 performs validity 
checking on the public key KpSP of the registration au- 
thority 1701. The validity checking is executed as 
processing in which, when the publk; key and public key 
certificate of the same user are stored in the database 
described with reference to Fig. 5, they are invalidated 
and a newly updated public key is validated. The public- 
key-certificate Issuer authority 1602 issues and regis- 
ters the newly updated publk: key certificate In the da- 
tabase. 

[0165] The public-key-certlfrcate issuer authority 

1602 uses the private key KsIA of the public- key certif- 
icate issuer authority 1 602 to sign the generated publk; 
key certifteate, namely, IA«SP>», generates data £^$2 
({IA«SP»)sig.KsiA) '^y performing encryption using the 
session key Ks generated in the cross certification 
processing, and transmits the generated data to the root 



registration authority 1 601 . The root registration author- 
ity 1601 verifies the signature and uses its private key 
to sign the received data, and encrypts the signed data 
by using the session key (the session key generated in 

5 the cross certification processing executed between the 
registration authority 1701 and the root registration au- 
thority 1 601). The root registration authority 1 601 trans- 
mits the generated data to the registration authority 
1 701 . After decrypting the received data using the ses- 

10 sion key, and verifying the signature, the registration au- 
thority 1701 stores the certificate. 
[0186] Similarly to Fig. 20, Fig. 21 is an illustration of 
a procedure for issuing a new public key and private key 
certificate of a service provider as the registration au- 

'5 thority 1701 under management by the root registration 
authority 1601 . However, in Fig. 21 , the new public key 
and private key of the service provider are generated by 
the root registration authority 1601. 
[0187] Fig. 21 differs from Fig. 20 in steps (2) to (6). 

20 These steps are described. The registration authority 
1701 and the root registration authority 1601 execute 
cross certifkation processing. This is performed using 
cross certlftoation keys (corresponding to the key Kab 
described with reference to Fig. 13) that are stored be- 

25 forehand in, for example, memories of the registration 
authority 1701 and the root registratton authority 1601, 
or using the present publk; key and private key (see Fig. 
14). 

[01 88] Next, the registration authority 1 701 uses its pri- 

30 vate key K^p to sign the identifier SPiD of the registration 
authority 1701, generates data EKs({SPID)sig.KsSp) ^y 
performing encryption suing the session key Ks generat- 
ed in the cross certification, and transmits the generated 
data to the root registration authority 1 601 . After using 

35 the session key Ks to decrypt the received data, and ver- 
ifying the signature, the root registration authority 1601 
recognizes the identifier SPID. Having recognized it, the 
root registration authority 1601 generates a new public 
key and private key of the root registration authority 1 601 . 

^0 After that, the root registration authority 1 601 uses its pri- 
vate key to execute signing processing on the generated 
pubib key and private key of the registration authority 
1 701 , encrypts them using the session key. and transmits 
ttie encrypted keys to the registration authority 1 701 . The 

<5 subsequent steps are similar to those in Fig. 20. 

[0189] Next, with reference to Fig. 22, revocation 
processing on a public key certificate is described. Al- 
though Fig. 22 shows the revocation processing as 
processes among the user 2001 , the root registration 

so authority 1 601 , and the publk:-key-certif icate issuer au- 
thority 1602, if there Is the registration authority 1701 
between the user 2001 and the root registration author- 
ity 1601, the registration authority 1701 affects commu- 
nk:ation between the user 2001 and the root registration 

55 authority 1601. 

[0190] The processing in Fig. 22 is described. The 
root registration authority 1 601 performs processing for 
revocation when the public key of the user 2001 Is, for 
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example, unlawfully distributed, or In accordance with a 
request from the user 2001 . This is executed as the 
process of adding the public-key information of the user 
2001 to the revocation list described with reference to 
Figs. 9 and 10. The root registration authority 1601 per- 
forms registration to the revocation list, and requests the 
public-key-certificate issuer authority 1602 to perfomn 
invalidation of the public key certificate. 
[0191 J First, the root registration authority 1601 and 
the public-key-certificate issuer authority 1602 execute 
cross certification processing. When certification is es- 
tablished, the root registration authority 1601 uses the 
private key of the root registration authority 1 601 to sign 
the identifier SAMISD of the user 2001, which corre- 
sponds to a revoked public key, and the public key 
KpUD, generates Eks((SAMID. KpUDlsig.KsRootSp) by 
performing encryption using a session key generated in 
the cross certification, and transmits the generated data 
to the public-key-certificate issuer authority 1 602. 
[0192] After decrypting the received data Eks({SA- 
MID, KpUD}sig.KsnootSp)« verifying the signature, 
the public-key-certificate issuer authority 1 602 perfonms 
invalidation processing on the public key certificate cor- 
responding to the publk: key K|3UD of the user 2001 . In 
other words, a flag in the database described with ref- 
erence to Fig. 5 is set to indicate Invalidation. The publlc- 
key-certlficate Issuer authority 1602 transmits, to the 
root registration authority 1601, data E^^J^{OK/ 
NG)sig.K5jA) obtained such that a response that Indi- 
cates whether the invalidation processing has been ex- 
ecuted (OK or NG) is signed and is encrypted using the 
session key. 

[0193] When the revocation processing on the public 
key certificate, which Is consecutively performed, ends, 
the publto key of the user 2001 is not allowed to be used 
under a service managed by the root registration author- 
ity 1801. In other words, transmission/reception and ver- 
ification of data encrypted using the public key cannot 
be perfomied with the root registration authority 1601, 
and also with another service provider managed by the 
root registration authority 1601, dealing using the re- 
voked public key is impossible. The root registration au- 
thority perfonms the differential distribution of the revo- 
cation list, as required. 

[0194] Fig. 23 illustrates the process of validating a 
revoked public key and a revoked public key certificate. 
When a public key is revoked, the user 2001 is denied 
(NG) access to the root registration authority 1601. 
When the root registration authority 1 601 validates the 
revocation of the revoked public key, the root registra- 
tion authority 1601 issues a certificate invalidating re- 
quest to the publlc-key-certlficate issuer authority 1 602, 
and cross certification processing is executed between 
the root registration authority 1601 and the public-key- 
certif icate issuer authority 1 602. 

[0195] When cross certification is established, the 
root registration authority 1601 uses the private key of 
the root registration authority 1601 to sign the identifier 



SAMISD of the user 2001 , ^ich corresponds to the 
public key to be validated, and the public key ICpUO, 
generates Eks({SAMID, KpUD}sig.KsRootSp) by pertomi- 
ing encryption using a session key generated in the 

s cross certification, and transmits the generated data to 
the publk;-key-certificate issuer authority 1 602. 
[0196] After decrypting the received data Eks({SA- 
MID, KpUDlsig-KsRootSp)' verifying the signature, 
the public-key-certificate issuer authority 1 602 perfonns 

10 the processing of validating the revoked public key cer- 
tificate corresponding to the public key KpUD of the user 
2001 . In other words, the flag in the database described 
with reference to Fig. 5 is set to indrcate validation. The 
public-key-certifk;ate issuer authority 1602 also trans- 

»5 mits, to the root registration authority 1601, data E^s 
({OK/NG}sjg.KsiA) obtained such that a response that in- 
dk:ates whether the validation processing has been ex- 
ecuted (OK or NG) is signed and is encrypted using the 
session key. The root registration authority performs the 

20 differential distribution of the revocation list, as required. 
[0197] When the validation processing on the public 
key certificate, whteh is consecutively performed, ends, 
the public key of the user 2001 is allowed to be used 
under the servtoe managed by the root registration au- 

55 thority1601. 

[01 98] Fig. 24 is an illustration of the processing of 
deleting a public key certificate, in this case, the root 
registration authority 1 601 issues a certificate deleting 
request to the public-key-certificate issuer authority 

30 1 602, and cross certification processing is executed be- 
tween the root registration authority 1 601 and the publk:- 
key-certlf Icate issuer authority 1602. 
[0199] When cross certification is established, the 
root registration authority 1601 uses the private key of 

35 the root registration authority 1601 to sign the identifier 
SAMISD of the user 2001 , which corresponds to the 
public key to be deleted, and the public key KpUD, gen- 
erates EksWSAMID, KpUD}sig.KsRootsp) by perfomning 
encryption using a session key generated In the cross 

^0 certification, and transmits the generated data to the 
public- key-cert if k:ate issuer authority 1 602. 
[0200] After decrypting the received data E,(3({SA- 
MID, KpUD}sig.KsRoetsp)> verifying the signature, 
the public-key-certificate issuer authority 1 602 performs 

45 the processing of deleting the public key certificate cor- 
responding to the public key KpUD of the user 2001 . In 
other words, from the database described with refer- 
ence to Fig. 5, corresponding public-key information is 
deleted. The publte-key-certificate issuer authority 1 602 

50 also transmits, to the root registration authority 1601, 
data EKs({OK/NG)sig.KsiA) obtained such that a re- 
sponse that indicates whether the deletion processing 
has been executed (OK or NG) is signed and is encrypt- 
ed using the session key. 

55 [0201] When the deletion processing on the publk: 
key certificate, whksh is consecutively performed, ends, 
the public key of the user 2001 is not allowed to be used 
under the servk:e managed by the root registration au- 
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thority 1 601 . 

[0202] Next, an example of construction is described 
In which the registration authority is set as a system 
holder in a hierarchical structure composed of the root 
registration authority and the registration authority. 
[0203] The system holder is formed by, for example, 
an authority that organizes and manages an Internet 
shop market on the Internet, an authority that provides 
communication infrastructure for cellular phones, an au* 
thority that manages the use of cables for cable televi- 
sion, an electronic-money-card issuing body, or the like. 
In other words, the system holder is defined as an au- 
thority that provides and manages an Infrastructure for 
distributing contents or services which enables provi- 
sion of various contents and services and that manages 
devices. 

[0204] In Fig. 25 is shown an illustration of the rela- 
tionship among a system holder 2501 , a contents crea- 
tor 2502, a service provider 2503, and a user 2504, and 

In Fig. 26 are shown specific examples of the system 
holder, the contents creator, the service provider, and 
the user device. 

[0205] in Fig. 25, the system holder 2501 provides an 
infrastructure for distributing contents and services that 
can be used in the contents creator 2502, the service 
provider 2503, and the user (device) 2504. The contents 
creator 2502 and the service provider 2503 provide con- 
tents or services by using the infrastructure provided by 
the system holder 2501. The user (device)2504 re- 
ceives a service provided by the service provider 2503 
by using the infrastructure provided by the system hold- 
er 2501. 

[0208] In Fig. 26 are shown specific contents creator, 
service provider, and user device examples. As shown 
In Fig. 26, when the system holder is, for example, an 
Intemet-shop-market organizer authority, the contents 
creator provides goods to be provided to the Internet 
shop mari<et. The service provider is a shop that sells 
the provided goods In the Internet shop, and the user 
device is a PC or the like that uses the Internet shop. 
[0207] When the system holder is an authority that 
provides a cellular-phone communication Infrastructure, 
such as a communk:ation company or the like, the con- 
tents creator uses the cellular-phone communication in- 
frastructure to make and produce providable contents 
and goods. The service provider uses the cellular-phone 
communication infrastructure to sell and provide the 
contents and goods provided by the contents creator to 
users. In this case, the user devtee is a cellular phone. 
[0208] When the system holder is an authority that 
provides a cable television communication infrastruc- 
ture, such as a cable-television-cable-communication 
management company, the contents creator uses the 
cable-television communication infrastructure to make 
and produce providable contents and goods. Also pro- 
grams that are provided to the cable television are in- 
cluded in the contents. The service provider uses the 
cable-television communication infrastructure to sell 



and provide the contents and goods provided by the 
contents creator to the users, and is. for example, a ca- 
ble television company that directly collects audience 
charges from viewers. 
5 [0209] When the system holder is an authority that 
provides electronk: money settlement infrastructure, 
such as an electronk; money issuing authority, the con* 
tents creator is a content and goods providing authority 
that provides goods that can be used (purchased) by 
10 electronk: money, the service provider is a selling shop 
realized as a shop in whrch the contents and good pro- 
vided by the contents creator can be used using elec- 
tronic money. The user device Is an IC card to whfch 
electronic money is input, or the like. 
IS [0210] In addition, there are various types of system 
holders, and depending on the type of system holder, a 
contents creator, a servk:e provider, and a user devne 
are formed. In other words, the system holder is defined 
as an authority that provides and manages a contents 
20 or service providing Infrastructure enabling provision of 
contents and services usable by the user device. 
[0211] Here, a distribution constmctlon is described 
in which contents or sen^ices can be easily used for the 
users by controlling the system hoMer to implement the 
25 functions of the above-described registration authority. 
[0212] First, Fig. 27 is used to describe a public-key- 
cryptosystem distribution construction for contents or 
services in a form in whk:h the system holder is not pro- 
vided with the functions of the registration authority. 
30 [0213] As shown in Fig. 27, various types of servtees 
that can be used by the users exit. Each of the types 
uses Its unique pubiki key encryption, i.e., the issuance 
of a unique public key certificate that is effective only in 
a particular service by performing unique examination 
35 and unique registration, whereby the particular service 
is provided. Fig. 27 shows this conventional servkse pro- 
viding construction. In Fig. 27 are shown a group 2710 
that provides service A and a group 2720 that provides 
service B. 

40 [0214] The group 2710 that provides service A In- 
cludes a public-key-certiflcate issuer authority (lA-A) 
271 1 that is usable for providing servtoe A, a sen^ice pro- 
vider 271 4 that requests the use of a publk: key certifi- 
cate, and a registration authority (RA-A) 2712 that exe- 
45 cutes the registration and management of a user (de- 
vice) 2715. Based on an examination by, for example, 
an official examination authority 2713. the registration 
authority 2712 performs, the registration of the servk^e 
provider 271 4 and the user (device) 271 5, requests the 
50 public-key-certiffcate issuer authority (I A- A) 2711 to is- 
sue a certificate, and performs the management of the 
service provider 2714 and the user (device) 2715. The 
public-key-cerllficate Issuer authority (I A- A) 2711 and 
the registration authority (RA-A) 2712 constitute a cer- 
55 tifk:ate authority (CA-A). 

[0215] The group 2720 that provides service B in- 
cludes a public-key-certiflcate issuer authority (lA-B) 
2721 that is usable for providing servkse B, a service pro- 
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vider 2724 that requests the use of a public key certifi- 
cate, and a registration authority (RA-B) 2722 that exe- 
cutes the registration and management of a user (de- 
vice) 2725. Based on an examination by, for example, 
an cfficlal examination authority 2723, the registration 
authority 2722 performs, the registration of the service 
provider 2724 and the user (device) 2725, requests the 
public-key-certificate issuer authority (lA-B) 2721 to is- 
sue a certificate, and performs the management of the 
service provider 2724 and the user (device) 272S. The 
public-key-certificate issuer authority (lA-B) 2721 and 
the registration authority (RA-B) 2722 constitute a cer- 
tificate authority (CA-B). 

[0216] When, in this construction, the user 2715, to 
which a public key certificate usable in service A Is is- 
sued by perfomrtlng registration via the registration au- 
thority (RA-A) 2712 in order to be provided with service 
A, receives a service in service B, the issued public key 
certificate cannot be used. In order that the user 2715 
may receive a service in servrce B, it is essential to per- 
form a new registration procedure using the registration 
authority (RA-B) 2722 so that a new public key certifi- 
cate is issued. 

[0217] To solve this point, it is possible that certlfk^a- 
tion be performed by both the certificate authorities 
(CAs) that are each composed of the public-key-certifi- 
cate issuer authority and the registration authority 
shown in Fig. 27, or it Is possible that the certificate au- 
thorities (CAs) be formed to have a hierarchy, l-lowever, 
this causes a defect in a processing load in the certifi- 
cate authority increases and in that the certificate au- 
thority structure becomes complex. Otherwise, when a 
construction is employed in which a plurality of public 
key certificates corresponding to a plurality of services 
are stored in the device in order that the user may re- 
ceive the services, the storage area of the user device 
is much used to store the public key certificates. This 
construction causes a problem in a device having a lim- 
ited storage area, such as an IC card. 
[0218] When both the user devtee 271 5 and the user 
device 2725 In Fig. 27 perform cross certification in of- 
fline, both have different certificate authorities that con- 
trol them, the cross certification cannot be executed. In 
order that cross certification may be effectively execut- 
ed, both a public key of a certificate authority that con- 
trols a device itself and a publk; key of a certificate au- 
thority that controls an associated devk:e must be stored 
in the devices, so that the number of publte keys to be 
stored Increases more when certification with various 
associated devices is required. 
[021 9] In the construction in Fig. 27 that perforn^s in- 
dependent management for each servce, various prob- 
lems occur. It is a construction shown in Fig. 28 in which 
each system holder is positioned at a hierarchy below 
each root registration authority that soh/es the problems. 
[0220] The construction in Fig. 28 is described. The 
construction in Fig. 28 corresponds to that in Fig. 27, 
and Includes a group of service providers in which the 



left one provides servk:e A and the right one provides 
service B. A servk;e provider 2804 is a body providing 
service A. and a service provider 2807 is a body provid- 
ing servk^e 6. 

s [0221] The service provider 2804, a user (device) 
2805, the servtee provider 2807, and a user (device) 
2808 are subjects to be certificated, namely, bodies that 
execute data transmission and reception using public 
key encryption. Although Fig. 28 shows the construction 

10 con-esponding to two servtees A and B, many services 
can exist. 

[0222] The system holder A (2803) acts and functions 

as the above-described registration authority. The serv- 
ice provider 2804 and the user (device) 2805 as subjects 

IS to be certificated, whbh are under the control of the sys- 
tem holder A, request the system holder A (2803) to is- 
sue public key certifteates. The system holder B (2806) 
receives public-key-certificate issuing requests from the 
sen^ice provider 2807 and the user (device) 2808. 

20 [0223] Each of the system holder A (2803) and the 
system holder B (2806) certificates subjects (entities 
participating in servk^e, apparatuses) in each service. 
Each of the system holder A (2603) and the system hold- 
er B (2806) receives a public-key-certificate issuing re- 

25 quest about a publk; (entity participating in service, ap- 
paratus) key used by a subject In each service, and 
transfers it to a public-key-certifk:ate Issuer authority 
2801 via a root registration authority 2802. The root reg- 
istration authority 2802 accepts public-key-certificate Is- 

30 suing requests from the system holder A (2803) and the 
system holder B (2606), which are certificated. In other 
words, the root registration authority 2802 receives a 
public-key-certificate issuing request when the request 
is from the system holder A (2803) or the system holder 

35 B (2606), which is certificated by the root registration 
authority 2802. 

[0224] In Fig. 28, the service provider 2804 and the 
service provider 2807 are servk:e providers that execute 
provision of servtee for distributing contents such as mu- 
40 sic data, image data, and game programs, and are 
formed by the service providing bodies for providing var- 
ious servtees, which have been described with refer- 
ence to Rg. 26. 

[0225] The system holder A (2803) and the system 
4S holder B (2806) are authorities that manage infrastruc- 
tures for realizing the servk:es provided by the service 
provider 2804 and the service provider 2807, and are 
formed by the cellular-phone-communicatlon infrastruc- 
ture provider, the electronk:-money/card issuing author- 
50 ity, etc., whk^h have been described with reference to 
Fig. 26. 

[0226] This embodiment is characterized in that a sys- 
tem holder that provides or manages an infrastructure 
for realizing provision of contents and provision of serv- 
55 k:es operates as an Interagent In public-key-certifk:ate 
certification and issuance of public key certificates of a 
data -communication Implementing service provider and 
user device, and performs management of registration. 
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Since the system holder is an authority that provides or 
manages an infrastructure (or enabling provision of con- 
tents and provision of services, the system holder per- 
fomns, in many cases, the management of users and 
service providers that use the infrastructure, and usually 
includes a management database. By using the man- 
agement database to also perform the management of 
public-key-certificate receivers, efficient management 
of users or service providers can be executed. 
[0227] When a new communication infrastructure is 
constructed, and a new system holder appears, by set- 
ting the new system holder to be under the control of an 
existing root registration authority and public- key-certtf- 
icate issuer authority, a public-key-certificate issuing 
construction using the new infrastructure is easily real- 
ized, and provision of service using the new infrastruc- 
ture is realized. 

[0228] The user device can be controlled to use vari- 
ous services such that one public key certificate Is only 
stored in the user device. In other words, since in the 
construction in Fig. 28, one root registration authority 
and one public-key-certiricate issuer authority are set to 
correspond to the system holders and the service pro- 
viders, the user device can use different services by re- 
taining one public key certificate. In addition, between 
user devices which are under the control of different sys- 
tem holders, cross certification can be performed using 
a public key issued by one common public-key-certifi- 
cate issuer authority. 

[0229] Next, Fig. 29 is used to describe a specific con- 
struction for the use of a public key certificate in the pub- 
lic-key-certificate issuing system and data communrca- 
tion method of the present invention. 
[0230] The construction in Fig. 29 includes a publtc- 
key-certificate issuer authority 2901 for performing pub- 
Ik; key management and public-key-certificate issu- 
ance, an entity, namely, a root registration authority 
2902 for perfonning recognition processing for a subject 
to be certificated that requests issuance of a public key 
and a public key certificate, a service provider 2903 as 
a registration authority, a clearing center 2904. and a 
user terminal 2905. 

[0231) The registration authority 2902 Is certificated 
by the public-key-certificate issuer authority 2901 , and 
possesses a public key and private key of the root reg- 
istration authority 2902. and a publk: key certificate. A 
public key of the root registration authority 2902 and a 
public key of the publte- key-certificate issuer authority 
2901 are posted to the service provider 2903 as a reg- 
istration authority which is under the control of the root 
registration authority 2902, the clearing center (payment 
RA) 2904, and the user terminal 2905, or are embedded 
in each apparatus. 

[0232] The service provider 2903 and the clearing 
center 2904 register identifiers in the root registration 
authority 2902, and obtain public key certificates issued 
by the public-key-certifrcate issuer authority 2901 (proc- 
ess 2 shown). 



[0233] To receive a service from the service provider 
2903, the user terminal 2905 registers an apparatus by 
transmitting a unit identifier to the registration authority 
as the servk:e provider 2903 via an SAM (Secure Appii- 
5 cation Module) of the user terminal 2905 (process 3 
shown). 

[0234] After verifying whether a user terminal identi- 
fied for a service provider (e.g., a sen/ice provider or 
shop not shown) by a unit identifier can use a service, 

10 the registration authority as the service provider 2903 
issues a public key certificate via the public-key-certifi- 
cate issuer authority 2901. The user terminal 2905 
stores the issued public key certificate in the SAM of the 
user terminal (denoted by 4 shown). These processes 

IS enable the user terminal 2905 to perform public-key da- 
ta communication in the system shown in Fig. 29 and to 
receive the provided servtee. 

[0235] To receive a service from the clearing center 
(payment RA) 2904, the user terminal 2905 registers an 
20 apparatus by transmitting a unit identifier to the regis- 
tration authority as the service provider 2903 via the 
SAM (Secure Appltoation Module) of the user terminal 
2905 (process 6 shown). 

[0236] When executing payment processing on con- 

25 tents charges by means of the clearing center 2904, us- 
ing electronic money stored in the user terminaFs SAM, 
the user terminal 2905 registers the identifier of the user 
' terminal 2905 in the clearing center 2904. 

[0237] The clearing center 2904 perfonns credit con- 

30 trol, etc. , for a settlement authority such as a bank, Men- 
tifies a user (payer), and issues a public key certificate 
via the root registration authority 2902 and the public- 
key-certificate issuer authority 2901 . The user terminal 
2905 stores the issued public key certificate in the user 

35 terminal's SAM (process 7 shown). 

[0238] When being provided with a service managed 
by the service provider 2903. the user terminal 2905 us- 
es the public key certificate received via the service pro- 
vider 2903. When using the service of the clearing cent- 

40 er 2904, or performs payment processing, the user ter- 
minal 2905 uses the publk: key certificate obtained by 
the clearing center 2904. 

[0239] When the clearing center 2904 needs to direct- 
ly use the public key certificate transferred to the user 

45 terminal via the sen/ice provider 2903, the clearing cent- 
er 2904, public-key-certificate generating processing 
via the clearing center 2904 is not performed, and by 
performing processing in both the clearing center 2904 
and the root registration authority 2902, an already gen- 

50 erated publk: key certificate Is used as an effective pub- 
lic key certifteate for settlement by the clearing center 
2904. 

[0240] As described above, the present invention has 
been fully described with reference to particular embod- 
55 rments. However, it is obvious that a peraon skilled in 
the art can modify or substitute the embodiments within 
the spirit of the present invention. In other words, the 
present invention has been disctosed in the form of em- 
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bodtments, and should not be interpreted in a limited 
sense. To understand the spirit of the present invention, 
the appended Claims should be considered. 



Claims 

1. A public- key-enciyption data-communication sys- 
tem comprising: 

a public-key-certificate issuer authority for issu- 
ing a public key certificate corresponding to a 
subject to be certificated, the subject perfomi- 
ing data transfer using public key encryption; 
a root registration authority for executing mutu- 
al data transfer with said public-key-certificate 
issuer authority, said root registration authority 
perfomriing certification ol the subject when the 
subject is under the control of said root regis- 
tration authority and requesting said public- 
key-certiftcate issuer authority to issue the pub- 
lic key certificate corresponding to the subject; 
and 

a registration authority for executing mutual da- 
ta transfer with said root registration authority, 
said registration authority performing certifk:a- 
tion of the subject when the subject Is under the 
control of said registration authority and re- 
questing said root registration authority to issue 
the public key certificate corresponding to the 
subject. 

2. A public- key-encryption data-communication sys- 
tem according to Claim 1 . wherein: 

said root registration authority treats a plurality 
of registration authorities as subjects to be cer- 
tificated; and 

each of said plurality of registration authorities 
treats, as a subject to be certificated, one of at 
least one service provider, at least one user ter- 
minal, and at least one user whksh are under 
the control of the registration authority. 

3. A public-key-encryption data-communication sys- 
tem according to Claim 1 , wherein said registration 
authority or at least one service provider which is 
under the control of said registration authority ap- 
plies, to a plurality of different services, a public key 
certificate corresponding to a subject to be certifi- 
cated whteh is under the control of said registration 
authority or of said at least one service provider 
which is under the control of said registration au- 
thority. 

4. A public- key-encryption data-communication sys- 
tem according to Claim 1 , wherein: 
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said root registration authority includes, as one 
of a plurality of registration authorities as sub- 
jects to be certif rcated whk:h are under the con- 
trol of said root registration authority, a clearing 
center for executing settlement processing; 
and 

in processing using a public key certificate 
which is issued via said clearing center, settle- 
ment is performed which relates to a service 
provided by a registration authority other than 
said clearing center which is under the control 
of said root registration authority or by at least 
one service provider which is under the control 
of said registration authority other than said 
clearing center. 

5. A public-key-encryption data-communication sys- 
tem according to Claim 1 , wherein: 

. said public-key-certlficate issuer authority 
holds a list of the correspondence among public 
keys and corresponding publk: key certificates, 
and the identifiers of subjects to be certificated 
for which the public key certif nates are issued; 
and 

either said root registration authority or said 
registration authority holds entity data whteh 
correspond to the subjects and which include 
certification data on the subjects. 

6. A public-key-encryption data-communication sys- 
tem according to Claim 1 , wherein: 

the public key certificates each include an elec- 
tronic signature field for an electronic signature 
of said publte-key-certlflcate issuer authority; 

and 

a plurality of algorithms are used as a signature 
algorithm forthe electronic signature generated 
in said electronic signature field, and the public 
key ceriificates each include a field identifying 
the used algorithm. 

7. A public-key-encryption data-communication sys- 
tem according to Claim 1 , wherein: 

in data transfer between said public-key-certif- 
icate issuer authority and said root registration 
authority, cross certification processing is per- 
formed, and when the cross certification is es- 
tablished, mutual data transfer is executed; 
in data transfer between said root registration 
authority and said registration authority, cross 
certification processing is performed, and when 
the cross certif toation is established, mutual da- 
ta transfer is executed; and 
in data transfer between said registration au- 
thority and the subject, cross certification 
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processing is performed, and when the cross 
certification is established, n^utual data transfer 
is executed. 

A public-key-encr^tion data-communication sys- s 
tern according to Claim 1 , wherein, between two 
among said public-key-certificate issuer authority, 
said root registration authority, said registration au- 
thority, and the subject, data is transferred in a form 
in which said data includes a generated electronic io 
signature of a data transmitting side. 



13. A public-key-encryption data -communication sys- 
tem according to Claim 1. wherein said root regis- 
tration authority controls a plurality of system hold- 
ers whteh provide or manage an infrastructure for 
distributing different contents or services, receives 
a public-key-certificate issuing request via one of 
the system holders from one of at least one servtee 
provider and at least one user terminal which are 
under the control of the one system holder, and re- 
quests said public-key-certificate issuer authority to 
issue a public key certificate. 



9. A public-kcy-encryption data-communication sys- 
tem according to Claim 1, wherein at least one of 
said root registration authority and said registration 
authority possesses a revocation list concerning 
publk; key certificates corresponding to subjects 
which are under the control of said at least one, ex- 
ecutes the updating of said revocation list, and re- 
quests said public-key-certif cate issuer authority to 
perform data processing conresponding to the up- 
dating. 



14. A public-key-encryption data-communication sys- 
tem according to Claim 12, wherein; 

IS 

under the control of said system holder, said 
system holder has contents creator which per- 
forms provision of contents by using a distribu- 
tion Infrastructure for contents or a service, pro- 
20 vided or managed by said system holder; and 

said system holder treats saki contents creator 
as a subject to be certificated. 



10. A publk:-key-encryption data-communication sys- 
tem according to Claim 1 , wherein at least one of 
said root registration authority and said registration 
authority requests the Issuance of a plurality of pub- 
Ik: key certif nates corresponding to a plurality of 
services which are under the control of the one au- 
thority. 

11. A pubtic-key-encryption data-communteatlon sys- 
tem according to Claim 1 , wherein: 

the public key certifteate includes a common 
electronic signature of said public-key-certifi- 
cate issuer authority which issues the public 
key certificate; and 

one of a root registration authority, a registra- 
tion authority, a service provider, and a user de- 
vtee whch pert omn processing for the verifk:a- 
tion of one public key certificate Issued by said 
publk;-key-certificate issuer authority perfomns 
offline processing for the verification of different 
publte key certificates issued by a single public- 
key-certifk;ate issuer authority. 

12. A publk:-key-encryptlon data-communteation sys- 
tem according to Claim 1, wherein: 

said registration authority is formed as a system 
holder as an authority which provides or man- 
ages a distribution infrastructure for contents 
which are usable by a user terminal, contents 
for use in providing a service, or a service; and 
said system holder controls and treats a service 
provider and said user terminal as subjects to 
be certificated. 



15. A public-key-encryption data-communication sys- 
25 tern according to Claim 1, wherein a user devk;e 

which is under the control of a plurality of different 
system holders controlled by a common public-key- 
certificate issuer authority has a public key of sakj 
common publte-key-certiflcate Issuer authority. 

30 

16. A public-key-encryption data-communication-sys- 
tem forming method comprising the steps of: 

requesting, by a subject to be certificated, a 
3S registration authority to issue a publk: key cer- 

tificate; 

transferring, from said registration authority to 
a root registration authority certificating said 
registration authority, a public-key-certlficate 

40 issuing request from the subject; and 

transfening, from the root registration authority 
to a publk:-key-certificate Issuer authority cer- 
tificating the root registration authority, the pub- 
ilc-key-certificate issuing request from the sub- 

4s ject. 

17. A public-key-encryption data-communication-sys- 
tem fonming method according to Claim 1 6, where- 
in: 

so 

said root registration authority treats a plurality 
of registration authorities as subjects to be cer- 
tificated; and 

each of said plurality of registration authorities 
S5 treats, as a subject to be certificated, one of at 

least one service provider, at least one user ter- 
minal, and at least one user which are under 
the control of the registration authority. 
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18. A public-key-encryption data-communication-sys- 
tem fomiing method acconjing to Claim 16, wherein 
said registration authority or at least one service 
provider which is under the control of said registra- 
tion authority applies, to a plurality of different serv- 
ices, a public key certificate corresponding to a sub- 
ject to be certificated which is under the control of 
said registration authority or of said at least one 
service provider which is under the control of said 
registration authority. 

19. A public-key-encryption data-communk:atlon-sys- 
tern f omning method according to Claim 1 6, where- 
in: 

said root registration authority irtcludes, as one 
of a plurality of registration authorities as sub- 
jects to be certificated which are under the con- 
trol of said root registration authority, a clearing 
center for executing settlement processing; 
and 

in processing using a public key certificate 
which is issued via said clearing center, settle- 
ment is performed which relates to a service 
provided by a registration authority other than 
said clearing center which is under the control 
of said root registration authority or by at least 
one service provider which is under the control 
of said registration authority other than said 
clearing center. 

20. A public-key-encryption data-communication-sys- 
tem forming method according to Claim 1 6, where- 
in: 

said public-key-certificate issuer authority 
holds a list of the con-espondence among public 
keys and corresponding public key certificates, 
and the identifiers of subjects to be certificated 
for which the public key certificates are issued; 
and 

either said root registration authority or said 
registration authority holds entity data which 
correspond to the subjects and which include 
certification data on the subjects. 

21. A publk;-key-encryption data-communk:ation-sys- 
tem fomiing method according to Claim 1 G, where- 
in: 

in data transfer between said public-key-certif- 
icate issuer authority and said root registration 
authority, cross certification processing is per- 
fomned. and when the cross certification is es- 
tablished, mutual data transfer is executed; 
in data transfer between said root registration 
authority and said registration authority, cross 
certif icatk>n processing is perfomned, and when 



the cross certification is established, mutual da- 
ta transfer is executed; and 
in data transfer between said registration au- 
thority and the subject, cross certification 
5 processing is performed, and when the cross 

certification is established, mutual data transfer 
is executed. 

22. A public-key-encryption data-communication-sys- 
10 tern forming method according to Claim 1 6, where- 
in, between two among said public-key-certificate 
issuer authority, said root registration authority, said 
registration authority, and the subject, data is trans- 
ferred in a form in whk:h said data includes a gen- 
erated electronic signature of a data transmitting 
side. 

23. A public-key-encryption data-communication-sys- 
tem fonning method according to Claim 16, wherein 

so at least one of said root registration authority and 
said registration authority possesses a revocation 
list concerning public key certificates corresponding 
to subjects whk:h are under the control of said at 
least one, executes the updating of said revocation 

25 list, and requests said pubiic-key-certificate issuer 
authority to perform data processing corresponding 
to the updating. 

24. A publlc-key-encryption data-communication-sys- 
30 tem fomiing method according to Claim 1 6, wherein 

at least one of said root registration authority and 

said registration authority requests the issuance of 
a plurality of public key certificates corresponding 
to a plurality of services which are under the control 
35 of the one authority. 

25. A public-key-encryption data-communication-sys- 
tem fonming method according to Claim 16, where- 
in: 

40 

the publk; key certificate includes a common 
electronic signature of said public-key-certifi- 
cate issuer authority which issues the publte 
key certifrcate; and 

45 one of a root registration authority, a registra- 

tion authority, a service provider, and a user de- 
vice which perform processing for the verifica- 
tion of one publk: key certificate issued by sakJ 
public-key-certificate issuer authority performs 

so offline processing for the verif k:ation of different 

public key certificates issued by a single publb- 
key-certificate issuer authority. 

26. A public-key-encryption data-communication-sys- 
55 tem forming method according to Claim 1 6, where- 
in: 

said registration authority Is formed as a system 
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holder as an authority which provides or man- 
ages a distribution infrastructure for contents 
which are usable by a user terminal, contents 
for use In providing a service, or a service; and 
said system holder controls and treats a service s 
provider and said user terminal as subjects to 
be certificated. 

27. A public-key-encryption data-communication-sys- 
tem Jorming method according to Claim 26, wherein io 
said root registration authority controls a plurality of 
system holders which provide or manage an Infra- 
structure for distributing different contents or serv- 
ices, receives a public-I<ey-certificate issuing re- 
quest via one of the system holders from one of at is 
least one service provider and at least one user ter- 
minal which are under the control of the one system 
holder, and requests said pubtic-key-certiflcate Is- 
suer authority to issue a public key certificate. 

20 

28. A public-key-encryption data-communication-sys- 
tem fomiing method according to Claim 26, where- 
in: 

under the control of said system holder, said 25 
system holder has contents creator which per- 
fonxis provision of contents by using a distribu- 
tion infrastructure for contents or a service pro- 
vided or managed by said system holder; and 
said system holder treats said co ntents creator 30 
as a subject to be certificated. 

29. A public-key-encryption data-communication-sys- 
tem fonnning method according to Claim 26, wherein 

a user device which is under the control of a plurality 35 
of different system holders controlled by a common 
public-l<ey-certificate issuer authority has a public 
key of said common publk^-key-certificate issuer 
authority. 
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FIG. 7 
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FIG. 9 
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FIG. 10 
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FIG. 11 
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FIG. 12 



LET p BE A CHARACTERISTIC. LET a 
AND b BE COEFFICIENTS OF AN 
ELLIPTIC CURVE. LET THE CURVE BE 
y2 = x3 + ax + b. LET G BE A BASE 
POINT ON THE CURVE. LET r BE AN 
ORDER OF G, LET M BE A MESSAGE. 
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FIG. 16A 
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FIG. 18 
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